In a business that makes software, it is well known that one tactic for making large software is to break the problem and work down in to parts. Then the work is assigned to different people. What is less well known, in my opinion, is that when a problem is broken down and divided among people there still needs to be understanding of the system among each of the parts. In essence, the people that start out with the big problem divide and assign tasks, but it is important to remember to also assign understanding of the system as a whole to each part.
Sometimes taking the time and effort for each part to understand the system as a whole is considered waste. It takes time that cannot directly be quantified as producing code. The code that is produced by the individual will be for their part, so why do they need understanding of anything other than their tiny little problem?
The parts need to be able to answer the questions:
- What am I a part of?
- How do I interact with the other parts?
- Is the problem for my part designed correctly so that I may create the correct solution for the system? Read more about designing problems before designing solutions.
Interaction is not contained nicely within a part. Interaction should also be viewed from the perspective of the customer and not entirely from the perspective of the discipline of engineering.
For example, there is a large system that was developed at a company I know of where the mobile application used a red icon to represent a sale and the corresponding web site that displayed aggregated reports of sales used a red icon to represent that a sale was NOT made. Each part was certified to have accomplished their task individually correctly. In this case, the mobile application was considered a part of the system and assigned to an engineer and the web application was considered a part and assigned to a different engineer. Each was certified by the people testing to have accomplished their task correctly. Yet, the result was pure confusion if there was any user that was to use the mobile app and the web site.
What was lacking, was the mobile developer asking what they were building was a part of and the web developer asking what they were building was a part of. As engineers, they understood that the two sets of code were going to share a database. Yet, this fundamentally misses the point of understanding the system. Just because a database is completed and represents the entire set of data, does not mean it is the system. Even when implemented, the system is more a concept than any specific piece of technology. This is lost on some engineers that jump directly to implementations, pointing to specific tables of data.
If the question had been asked of each person who was responsible for building the parts, “What is this a part of?” and “How will this part interact with the other parts?” instead of saying “I have my part, I’m face down in implementing my part and I don’t need to waste my time with seeing what the other parts are up to.” then maybe a better system would have been developed from the perspective of the people who will be using the system. Something is always part of a larger system and to dismiss this in pursuit of optimum efficiency, getting your part out the door fast, is quick but not smart.
Successful software is the right software, not the fastest developed software.