Going Faster: Speeding up Software Development
Gregor Hohpe
Retired from big tech. Not retired from riding the Architect Elevator to make IT and architecture a better place. Have opinions on EA, platforms, integration, cloud, serverless.
Traditional project management has a fairly rational approach to speeding up projects. The project management triangle shows that a project can move along the axes of scope, how much work is to be done, resources, how much money and people you have, and time, how long the project takes. If you want a project done faster, add people or remove scope.
I recently presented this triangle to a group of senior IT staff and asked whether any of their managers are using this model to manage IT projects. My suggestion was to fire those managers (or to be more politically correct, to have a serious talk with them). If you manage software projects by the traditional triangle alone, you are missing the biggest levers in software development and will never be able to compete in economies of speed. Fred Brooks' Mythical Man Month from 1975 should have given you a hint.
Software projects are special in that they are a combination of design and manufacturing. Software is designed and coded by humans and then manufactured into an artifact that can be deployed into production. Understanding the malleability of software (pun intended) and this special aspect, one can identify the three real levers for faster software delivery, which don't result in 10% improvements, but in 2x or even 10x:
- Remove friction. Software projects can be full of friction: a developer waiting for the environment to be setup. a new server taking 2 weeks to be provisioned, manual testing cycles, long alignment meetings, etc. Taking this friction out can be like strapping a rocket booster on your ailing car. The best way to do so, is to Never Send a Human to Do a Machine's Job, i.e. to automate everything: environment setup, deployment, configuration, testing. Don't manufacture software like they assembled cars 100 years ago!
- Reduce inventory. Unfinished inventory is the root of much evil: it ties up capital without being able to generate revenue. A lot full of brand-new cars that are missing the ignition key would make any CFO go through the roof. Ironically, this is what many software projects look like: brand-new source code is checked into the repository but is waiting for the next product release cycle in 6 months. Even though this inventory is not visible it ties up capital: on a large project with 100 developers, a release cycle of 6 months (roughly 100 working days) can tie up 10,000 developer days - in the region of $10 million! That's not peanuts. Worse, inventory rots. A lot full of cars is one thing - a lot of fresh fruits, another. In the digital age, software is more like fruits - it rots and decreases in value fast. The lever to reduce inventory is to shorten release cycles or to allow independent releases of key modules.
- Eliminate unneeded work. Optimizing something that is not needed by 50% is still 100% waste. Software has the huge advantage of being malleable even late in the project cycle. One can also observe users using a software product to see which features are actually being used. This gives huge levers to reduce scope, scope that would not have provided value in the first place.
The middle of the project triangle is often occupied by quality, suggesting that by compromising quality you can break out of the equation of scope, resources and time. In software projects this is also not true - a topic for another post.
If the three software project levers above sound to you like DevOps, Lean, and Agile, you are spot on. Sadly, too many projects are tagged with these buzzwords but have not implemented the fundamental mechanisms behind them.
Learn 37 more things that one chief architect knows about IT transformation:
Feel free to contact me for in-house workshops coaching architects in IT transformation. Dan North also holds fantastic workshops on Faster Software.
V. interesting post. Re: unneeded work, I agree misunderstood or unneeded features generate a ton of unnecessary work. Do you think this is typically the key constraint? I think there's a rich taxonomy here related to quality dimensions like usability, performance, etc. and policy constraints like scheduling so maintenance or performance measures fester until they precipitate a crisis. How do you go about drilling down to root causes of that? How much are they the responsibility of an architect? Thanks for these posts, just ordered a dead tree copy of your new book!
Retired - Just playing golf
8 年Analogy with fruits works and sets up a view on a sw life cycle which is a perspective of a fruit fly. A serious elaboration can be done on that - let it (sw) live and rot (patches, addons) or (re)do it again and again. Try to think about consequences.
i would be happy to know about your guidelines/advice for microservices transition . thanks for article.