How to Move Fast in Software

Posted 3 weeks, 4 days ago | Originally written on 8 Jul 2021

Who wouldn't want all their features implemented immediately? It depends. How long will this software be used for? If it will be single-run code then nobody cares because it will not need any maintenance and we can always recreate it from scratch should any bugs rear their ugly heads. But if we want it to go the distance... that's another matter.

There is a limit on fast good software can be developed. At the very least, quality software is a function of the team's ability to adapt to the growing demands of the domain. For a team of one this will take a very long time though we can at least guarantee that the developer will have some memory of how the thing works. However, the moment you expand the team, you now have to think about all the dynamics this introduces. And a lot has been written about this...

At the very least you will need two parts to your team: architecture and development. Architecture makes the decisions on the overall structure so as to ensure that the product is fit for purpose and development realises the actual infrastucture. This is how it is done in the real world: the architects decide on the aesthetic and work with engineers to ensure that the building meets the client's requirements. Only when this is complete can construction begin. Even minor changes can have vastly complex implications. Why should it be any different with software?

Therefore, to move fast, at the very minimum will require these two roles.

But in addition to this, speed will obviously be far easier if the team has:

  • clear standards on how the code is written;
  • reasonable timelines within which to deliver;
  • regular exchanges to refine each other's skill;
  • excellent tools by which to achieve their tasks;
  • automations where necessary to eliminate repetitive tasks;
  • freedom to creatively solve the problem;
  • up-to-date knowledge on the state of the art of their craft.

Without taking these into account it is illusory for a team to move fast only to realise that they are increasely making their work harder and code more brittle. It will get to a point where you will realise that it is cheaper to start again than try to fix the mess you have engineered. As the Benjamin Franklin said, "Take time for all things; greate haste makes great waste".