Making decision in the software development is hard

This leads us to our next point. Because all new projects are custom built it follows that every line of code is unproven and therefore should be tested. However, in the real world, this is totally impractical. Each line of code will have dozens, even thousands, of possible inputs, outputs, states or dependencies to deal with. It can impact, or be impacted by, other lines of code or by external factors.

And testing a single line of code is only part of the challenge. No line of code exists on its own. It is part of the whole system and the whole needs to be tested to ensure that all parts of the application function correctly. The sheer complexity of software means it is impossible to test every path so in the real world the best project teams will implement processes that are designed to increase the likelihood of the software being defect free.

They will use techniques such as coding standards, unit testing, smoke testing, automated regression testing, design and code reviews etc. All of this testing comes at a cost. The question to be answered on every project is — how critical is this software and how much testing should we do to ensure the software is correct? Too often the testing phase is rushed and the software goes out with an unacceptable level of defects. On the other hand, for most systems there are diminishing returns for extending the testing past a certain point.

There comes a point with all software where the value of getting the software released is greater than the value gained by continuing to test for defects. This is why most commercial software gets released even though it is known to contain defects. For over 10 years the research company, The Standish Group, have surveyed companies about their IT projects.

The No. Without the involvement and input of a user representative the project is doomed to failure. This person should be a subject domain expert with the authority to make decisions and a commitment to the project timescales.

So assuming there is good user input then the challenge of translating requirements into a design begins. And this is no easy task as our next point shows. Even with good input from the users no amount of analysis of user requirements can take away an immutable fact that users only think that they know what they want.

It usually starts once the first designs begin to appear which cause the users to think more deeply about what they really want. There is no simple answer to this dilemma despite the fact that various techniques, such as Agile development, have evolved to make it easier to adapt to changing requirements. Even seemingly small changes can have a big impact on a project.

Each explicit requirement can lead to many more implicit requirements by a factor of up to 50 further complicating the software. Changing requirements during the development phase is one of the great challenges facing all software developers. There is one argument that states that software development is so hard because programming is so easy.

In other words it is relatively easy to learn how to write code but there is a huge gap between that and delivering great software. One could possibly equate it to learning a new language. Various studies have shown that the productivity ratio between different grades of developer can be as high as With that in mind it you surely would only want to hire the best developers. Unfortunately this is not easy as great developers are a very rare commodity. There is no barrier to entry into the programming world and thus it is awash with many poor programmers who adversely affect projects.

In addition, even potentially good young developers will still make mistakes that a more experienced developer will have learned to avoid. It really is worth paying more for a top-class experienced developer. They will do things quicker, and better and with less code. Your project will be delivered quicker and will have fewer defects. They will save you money now and they will also save you money through the life of the system in support and maintenance costs. Physical structures obey physical laws e.

Through thousands of years of learning much is known about the physical world and can therefore be modelled and predicted. Understanding and catering for all of these external factors is a near impossible task.

Even a seemingly simple requirement, such as supporting multiple browsers, exponentially increases the difficulty of both building and testing software. If you then add in a requirement to support multiple versions of each browser then you are again exponentially increasing the complexity and the difficulty.

Given the premise that all new projects are custom built, that there are no pre-built components, that the project will suffer from scope creep and that the level of skill across the development team is usually varied then it is no wonder that estimating the duration of the project can never be a scientific exercise.

There are too many unknowns. Furthermore, there is a certain point at which the rate of delivery becomes unsustainable and other aspects of the software business will begin to suffer such as culture, motivation and innovation.

Making better decisions is not only a necessary skill for management but for teams who deliver software as well since every decision has a flow-on effect.

Each bad decision might initially grant us a step forward but soon enough will take us a few steps backwards. Decades of research show that we easily fall victim to our default mental shortcuts aka cognitive biases and how they frequently rule the way we make decisions. In order to truly optimise and rapidly deliver software, ultimately business value and thus revenue, we need better discipline around the way we make decisions in software development.

The act of critical thinking seems to be It is possible to minimise or avoid teams from making the obvious bad decisions. Bad decisions are always more costly than we realise. But yet we continue to deliver software products that are late and over budget. Have we really made any significant progress in being better at delivering software? Or have we danced around the core problems? Change is not easy and sometimes a lot of hard work but growth can only happen when there is change. But nothing will change, unless we change!

Ultimately, making good decisions comes down to the speed and correctness that they are made. The problem description, its constraints and the different alternatives to solve it outputs from the previous process steps.

The art of making decisions is difficult but it will become an easy task if you did the previous steps correctly. Knowing your constraints and the available options, it should be possible to identify the best way to move forward.

Your goal during this meeting is to use all the information available to make a decision and plan the next steps. In those cases, people should just understand that not everybody is going to be happy about all the decisions that are made. You may know perfectly that you go for a non-optimal solution but that can be still the best alternative given the constraints and your knowledge at that time. What is important in each case is that you write down why you chose that option.

Use a Journal Entry to document the decision you made and the reasons behind it. The better you become at using this process, the better your Decision-Making mechanism will be.

Even though the decisions should be respected and followed for a while, you can always revisit these decisions when new information is available or constraints change. But the change should be always backed up by a good plan.

Continue reading this guide: Practical Software Architecture - Conclusions. Keeping an efficient Software Architecture can save you a lot of time, and also help build the foundations of a successful Software Project.

But, how to set up a way of working that is at the same time efficient, easy to implement and compatible with Agile methodologies? Part 1. Software Architecture: Issues and Solutions. Part 2. The Practical Architecture Process Overview. Part 3.