The three pillars of software development that can determine the success (or failure) of your project

 

Many researchers and scientists have studied the topics of software success, while others have studied the topic of software failure. In order to be able to grasp this broad topic, one should know where to start looking.

To improve the results of the outcome of a project, it would be useful to know what are the main pillars that a software project relies on. Like this, we would be able to identify better which parts need improvements.

While writing the book ‘On Understanding the Causes of Software Defectiveness’, I studied several sources addressing this topic and many of them define it with various terms. One of the research articles that I came across was from Robert Chiang and Vijay Mokerjee “Improving Software Team Productivity” . They had studied the improvement of software team productivity and in their work, they mention an approach oriented towards three pillars of software management: technology, people and process. I also came across a different terminology for the same pillars: system, team and process.

All of these pillars are interrelated, and so none of them could be excluded. Sophisticated compilers cannot improve performance if there is a lack of personnel or unskilled developers. The development process should be carefully managed as devoting time to less important activities could result in incapability to meet the deadlines. Priorities should be set appropriately for a process to be considered effective and efficient.

Sophisticated compilers cannot improve performance if there is a lack of personnel or unskilled developers. The development process should be carefully managed because devoting time to less important activities could result in incapability to meet the deadlines.

Usually, within the same organization the process design is the same for most of the projects, therefore, the outcome of a project – whether it is successful or not, could not be determined easily from this point of view. If you are experimenting with different processes for various projects then this might be an interesting topic to observe.

Let us take a look at each of the pillars in more details.

System
The System is a high-level overview of the project. In this pillar lay all the foundations that define the other pillars. First, a project starts with a requirements gathering and estimation. This would better define the Process and the size of the needed Team.
The methodology of estimation is also part of this pillar. You might have different methods for estimation that you would like to experiment with, in order to improve the outcome of the project. This group contains all the parameters that you would want to verify, including resources, methodology, costs, scopes and timeline.

The Process
This pillar is significantly more complex than the System. In this one, we are defining the choice of language or technology that we need to use. We need to carefully assess if we are using the correct tools and frameworks for our needs.
We also need to identify how many teams we are intending to have and how are they going to work? Are they going to be situated all in one building or remotely? Are they sharing the same time zones?
Part of the Process is also to identify the existence of technical analysis. Do you need to formalize and validate it? It usually depends on the project and the client. If you are writing software for a big corporation, bank or government institution you would probably need to formalize the analysis. Otherwise, if you are just starting a small project, probably this would take too much time.
As mentioned earlier the pillars are very interrelated. Defining whether you would want to have effective monitoring and control could be part of the System pillar, but it is also part of the process of creating the software.
The Process pillar includes also writing the software itself – creating new modules, or modifying existing ones, testing and identifying eventual defects and resolving them. Since the creation of code is also a part of the process – it would make sense to be able to observe its quality as well. There are various tools that you could use, I have mentioned some of them in the book, but SonarQube is a popular one. Of course, your preferred language or framework might have a more suitable tool for fitting better your needs. Testing the code itself is a topic worthy of having its own attention and I am planning to write about it soon.

The Process contains the creation of the estimations for length and complexity, but also the execution of the project itself.

The Team
The Team is an essential part of a software project. There are plenty of things to consider when forming a team for a project – experience, working experience in the domain of the project, age, gender and so on.
The Team is not limited to only people that write or test software, it includes also the project managers, scrum masters and other roles that you have in the process.
If you have a possibility to match newer, less experienced people with more experienced ones, this could be good training for the former. Age dynamics also play an interesting role. A team formed by people of similar age group (say 20 years old) would have different dynamics from a team of mixed and more balanced age.

Gender diversity is also important. I was involved in research to identify the outcomes of various projects in a company. It was interesting to find out that the more diverse people there were in a project, the fewer were the defects. This is not universal for every project, of course, but it is worth mentioning that diversity contributes to better quality.

In fact, diversity is so important that many companies would make personality tests and identify the dominant characteristics of people. They would then use the outcome to form a team. I will address the personality tests and diversity in another article soon.

In summary, the pillars of a software project can be grouped into three categories: The System, The Process and The Team. And since they are so tightly related, one could place certain parameters in one or more of these categories. Understanding better the dynamics of a team can improve the process and thus the quality of a software product. In fact, it might also be the cause of success or failure of a project. To learn more about this topic you can check ‘On understanding the causes of software defectiveness’ where I dive deeper into these and other parameters related to the outcome of a successful project.
Martin Anev Apptimist Studio
About me:
My name is Martin and I like to write about technology, business and travelling. I am a remote freelance software developer. I create websites and mobile applications, connect different business services through APIs, and other tech solutions for various problems. You can check my work and other articles at my company’s website Apptimist Studio: https://apptimist.studio/portfolio
I am an author of ‘Understanding the causes of Software Defectiveness’ — http://bit.ly/software_defects
Follow me on twitter: https://twitter.com/martianev
Follow me on Instagram: https://www.instagram.com/anev_martin/
Check more about what I do at: https://apptimist.studio

Leave a comment

Your email address will not be published. Required fields are marked *