An important and contentious topic within IT which, in my experience, closely relates to success is size:
- Size of change programs
- Size of a projects
- Size of a teams
- Size of software
- Size of classes/objects
- Size of functions/methods
People in the trenches of software development, i.e. the people cutting code, have learned some hard lessons about size which are equally applicable at all levels in IT. These lessons, when applied to the wider IT landscape within an organisation, can have a profound impact on success.
Starting in the trenches, good developers are acutely aware that the size of a function or method has a direct impact on code complexity, testability and readability: as size grows complexity increases and both testability and readability decrease. This also applies to class/object size in the OO paradigm where largeness can often be an indicator of breaking the single responsibility rule, possible poor abstraction
At a slightly higher level of abstraction, advocates of the microservice architecture similarly recognise the benefits of keeping things small. Rather than focusing on the more traditional monolith architecture the microservices approach focuses on developing suites of smaller, independently deployable services built around business capabilities . This focus supports a product over project approach – such as that seen at Amazon where they advocate “if you build it, you run it”, greatly enhancing the quality of the services by giving developers operational responsibilities.
Moving further from the trenches – and possibly further from the learned lessons of small is better – decisions about development team size is another which impacts on success. There is a limit to how many parallel streams which can be supported before code churn becomes too great; control over design is lost; communication channels fail and people become disillusioned? This limit varies depending on a number of factors: the product under development; languages and tech stack in use; experience of team members; maturity of the team; the architecture of the software. My experience is that a small, well honed team always outperforms larger teams. Most importantly a team doesn’t necessarily go faster when you throw more developers at it.
Project size is next in line for consideration. In my experience, and from discussion with colleagues in ThoughtWorks I’m not alone in this observation, smaller projects benefit from the momentum of fresh and motivated teams with a near term, clear goals. It always seems to be easier to define expected deliverables, get organisational support and stakeholder buy-in for short projects. Long story short: it becomes easier to succeed at delivery.
Finally, large IT change programs possibly provide some of the most notorious examples for avoiding large wherever possible. The National Health Service’s National Programme for Information Technology (NPfIT) is a great example. A McKinsey publication recently suggested that organisations should avoid building change programs which offer a top down, dictatorial approach and instead build change platforms where ownership of improvement is distributed across the organisation. For me that suggests that more regular, experimental and iterative improvements can be undertaken, i.e. smaller pieces of work.
Perhaps it’s a time we replaced the KISS acronym with KISSES:
KISSES: keep it simple stupid – especially small!