Industrializing Software Development – Part II

As the software market goes through a deep transformation, it is becoming critical to find the secrets of industrializing software development to remain competitive.

In the previous post, we mentioned the different challenges attached to a software development project. Before detailing the success factors in today’s world, let us emphasize some strong market trends. A recent Gartner study mentions that the enterprise application portfolio is composed of 75% of packaged software and about 25% of custom applications. And Gartner’s prediction is that in the future, it will be composed of 60% of packaged software, only 10% of pure custom applications and about 30% of composite applications, a new approach that is made possible thanks to Service-Oriented Architecture (SOA). It is quite natural to compare this to the consumer market and the development of “Mashup Applications”. Furthermore, maturation of the “Software as a Service” model, that deeply transforms the way software is consumed, adds additional kind of competition to development teams. More than ever, it is vital to consider development with an industrial and competitive approach.

FIRST, PEOPLE…

The regular reader might be surprised that we insist on people’s role, as the first part criticized the excessive weight of human factor. Still, contradiction is only an impression. As a matter of fact, there is no wealth but people, and no project whatsoever can be achieved without the leadership of at least one or two determined people. The specific phenomenon that we observe in software is that there are often too many decision-makers. If you can read French, I recommend Didier Quan’s book “L’impossible conduite du projet de SI” which well explains this point, in particular the number of people that often make architecture decisions on a project. Making an analogy with the building business, Didier Quan well explains this abnormality, which is not decided on purpose in most cases. 

In fact, two roles are particularly critical to the success of a software project development (provided that you have the right functional knowledge): the project manager and the architect. The first one needs real skills in project management, and human qualities to drive technical teams. It is very often necessary to have a minimum set of technical skills to be accepted by teams. However, his role needs to be distinct from the architect, and he needs to rely on him to make the right decisions and evaluate developer quality and commitment. The second one is certainly the hardest to find. Because the architect needs to design the overall technical solution, choose technologies and products to implement and define development rules. Considering the quick pace of technology evolution, it is a real challenge to find the optimal mix to optimize project equation (features cost and delay). This is why it is critical to get a pragmatic profile instead of a purist person that loves theoretical debates or strives for the ultimate solution. If these two roles are well fulfilled, it is often better to build a reasonably skilled development team of disciplined developers, while being very cautious about “software divas” that can quickly derail you from pragmatism.

THEN METHODOLOGY…

Once the team is formed, how should one lead a development project? Part of the secret is first in minimizing what is necessary to develop. “A good developer is a lazy developer!” have I learned at the beginning of my career. This principle is more than ever true. Developing is not a goal per se. This is first a way to fulfill a specific need, while standard solution is not fully adjusted. The limits of packaged software (or sometimes “standard” software as many packaged software are partly development platforms disguised in packaged products) lead you to consider developing. First, try to reuse functional services from the packaged software, while encapsulating them in SOA components (Service-Oriented Architecture), if the product provider does not already propose those interfaces! Furthermore, for the part that you really need to develop, do not reinvent wheel. Components and sophisticated tools can significantly limit your effort. By reducing the quantity of code, you will limit bugs, cost and delay. 

The second key methodology element is cooperation with the functional team. If you are about to develop, it is because you want to fulfill a need that is not fully commoditized. Without an optimal cooperation between development teams and functional experts, the expected benefits might never occur. Today’s tools are not yet capable of directly translating a functional requirement (or an update of this requirement) into an implemented component. This is why, without prescribing an absolute and unique methodology, we recommend favoring iterative approaches that avoid the tunnel effect and strengthen the cooperation between users and developers.

… AND OF COURSE TOOLS!

These pieces of advice being said, let us mention the third key success factor, related to technologies. ”There is no good worker without good tools” says popular thinking. And these tools can have a significant impact, as we are of course convinced at SoftFluent; this is why we developed CodeFluent! Tools to lead a development project are of diverse nature: development, design, testing, code analysis, lifecycle management, components, frameworks, code libraries, and repository or software factory.

Experience has shown us that the contribution of tools to project success is primarily a matter of choosing the right combination. Chosen tools need to be in line with the targeted architecture and work well together. On the contrary, selecting a tool for each function by just “checking boxes” often means “slippage”, long useless technical explorations and integration unanticipated costs. 

On the other hand, one should wisely consider tools that structure developer work, including the possibility of developing mini-tools suited to the project. The developer—like the blacksmith— has an opportunity to build his own tools. It is a real leverage effect, if one does not fall into the trap of doing only this! The architect should propose the right balance, by playing a major decision role. 

As a conclusion, let us remember that the development project manager should first internalize the economic challenges he is assigned to. Understanding them, he will hire a pragmatic architect that will help him make the appropriate technological choices and balanced decisions, while always keeping in mind the overall economic equation. 

Daniel Cohen-Zardi & Simon Mourier