The art of the decision making in software development
Posted on Aug 31, 2018
Software development is state of the art engineering work. Although it’s often misleading to speak about engineering. That’s because those who don’t know what software development really is, they associate it with mechanical engineering, which is based more on hard components rather than constantly changing services.
It is true that software developers work with components as well. But all of those components can change and they are always adjusted with more focused business logic, configuration and custom code. No matter which components the developer chooses to use, he or she still needs to do the creative magic on top of it. This magic is all based on decision making with educated guesses or more typically gut feeling.
In mechanical engineering pieces are put more logically together based on their physical characteristics. If one part does not fit into picture, it’s very difficult to put together rest of the device. Unlike with software, in mechanical world other components cannot compensate lacking features so easily. Overall the physical form of the outcome already defines how complex the machine can get and how it is structured.
Software can be anything, only imagination is our limit. The user interface might consist of only one button, but under that button often lies millions of lines of more or less needed logic. Physical characteristic of the software (user interface) does not define how the actual software is built. Same solution can be implemented with 100 or 100 000 lines of code. It’s up to developer how he or she decides to approach the problem.
Because of this, the decision making is the ultimately most difficult question in software development: Which design patterns, tools, platforms, environments or frameworks should we use? Which features we should deliver to customer? Does customer actually need any of this? Should we write the application logic in methods, static functions or living objects? Should we approach the problem in agile way, or can we deliver results with strictly scheduled project plan?
A skilled software developer could start the project with an empty canvas: An editor and empty text file. Imagination only defines what is the next step after that. Typically, of course, the next step is to choose a framework that already gives some tools, services, templates and pieces of code to start with. This decision typically depends on developer’s knowhow instead of business need. But after that, we return back to empty canvas again and again with new questions to be answered.
Decision making happens on all levels: Business decisions, customer requirement decisions, architectural decisions, development decisions, process decisions and so on. Actually, there is not a single moment in software development project where decision making wouldn’t be the top question. We start from what we know from the past and we end up to do decisions that are unknown to us - thus simply hoping the best that it was a good decision.
That’s why an effective decision making must become the driving force in all development work: If there is not trace of the decision, then there is no decision at all. This means that we need to share and write down our decisions - either within code itself or then to stories that defined the developed feature. When decision making is shared already before the decisions are made, then rest of the team has at least possibility to provide feedback and affect to it.
Decision making is not about documentation, but rather it's about collaboration. Developers must be capable to share their decisions with each other as well as managers and business people so that everyone in the organisation understands where we are at the moment. Apart from collaboration tools such as Jira, Github or Trello - decisions must be also shared in demo events, daily standups and planning meetings. Only shared decision can leave the trace, which allows other team members to follow that path and make new decisions based on the current facts.