The development of any system faces various problems over time by increasing the entropy of the source material. However, this problem is magnified greatly when the system is born with conceptual problems.
A Wrong Initiative …
As incredible as it could be, Paulo Maluf (yes, the politician) coined one of the most interesting phrases for those who design embedded systems. I think of it whenever some genius decides that thing that are working well and are very well crafted should be redesign because he, the genius, just think it should:
The most dangerous thing is a stupid person with initiative.
~ Paulo Maluf
When this stupid resolves to get hands on or when bad resource allocation has he working in the definition stages of a project, we will certainly have in the near future the old problem of keeping legacy stuff that can not be repaired.
When the Thing Catches
Some things are born with a fundamental defect and unfortunately they end widespread. So “dictatorship off the most” makes it standard. And here we go.
In the design of systems in general, over the project lifetime, implementation and testing cycles alternate to eliminate misconceptions of developers or their failures in understanding some task. For example, one might have wanted to do A instead of B. Or a designer thought he had made A, but instead he got B as result. We all call this a bug. It is normal, and we have tools to solve it: the good old couple of verification and validation.
I will use the example of the calendar to be more clear. To me, the calendar was the result of something that resulted from bad definition and it is obvious that as they began to organize the days in cycles, no one was fully aware of the problem. Due to this poor knowledge of the details of the problem, at some point someone realized there was a slip on the dates. Then someone finally measured the right the length of a year and concluded: we need an extra day, from time to time. Since then, we have been doing hacks. Nasty hacks.
- We have 365/366 days a year.
- 6 months with 31 days.
- 5 months 30 days.
- 1 month in 28/29 days.
- And this is the second month of the year.
All because someone as hardwired to the idea that the year must have 6 months with 31 days. The example of the calendar is, to me, the best example of maintaining a bogus specification. Let’s look at an alternative:
- We have 365/366 days.
- A good number to split the year is, in fact, 12.
- Let’s reclaim what is good.
- 365 ÷ 12 = 30 and rest 5.
- 7 months 30 days
- 5 month 31 days.
- One month (7 months 30 days) will, every four years, have 31 days.
- This special month is not the second, but the last the extra day in LIFO style, takes place in December.
Elegant, simpler and better, more symmetrical. But … It will never work out or come to reality. It is impossible to change the huge current structure without a lot of headache. It is one fact: the longer it takes to leave a bad standard, the worse it is going to get to change it. The current calendar is now a standard; a poor one.
The calendar case is a great example. It brings me back on to how many times developers are “blessed” to inherit a poorly crafted bad job, not because of poor execution quality, but rather a ridiculously definition and the inevitable result of a product that sucks.
Defective by Definition
I use to call products full of defects as defective by design. This is not the case. When a product is imagined in such a way that no matter how good it is implemented, the result will be something difficult to use, functionally impaired, or non durable, I call it “defective by definition”.
Products in this category tend to generate an absurd workload and absurd amount of maintenance effort to try to unsuccessfully overcome its inherent defects. Everything gets worse when when people start the add-ons.
“We are going to add a daughterboard” or “is an independent system.” They begin to stick things in the system to patch the problems and the end result is a Frankenstein that no one else understands that standardized a lot of nonsense and that no one else can figure how it is working.
Until, one day, we get to the paradox of “non-causal solution.”
The Non-Causal Solution
The problem of “poor standards” is a fun subject to an outsider. Very sad for those who see it from the inside. I have seen dialogues like this:
-Dev1: Who made this software is no longer here and it was very poorly documented. Better not to touch it.
-Dev2: Ok, then we go find some compatible hardware. We’ll have to move the hardware.
-Dev1: We can not tamper with the hardware, as we have many products in stock.
-Dev2: And where should we change to solve the problem?
-Dev1: That’s the same problem. We can’t touch anything to solve the problem.
-Dev2: And how do we solve?
-Dev1: That is just what we’re trying to figure.
Luckily, I was not the one to solve this beast. I could just to stood aside and have a laugh on the inside. Obvious that my comment on this was that decision should be presented to the hardware manager, software manager and production manager, as someone would have to bear the costs of change and solve the problem.
A flawed specification damages a product beyond repair. But the worst of this situation is that it screws up great development techniques, such as scalability and modularity. They are turned in instruments to make quick fixes.
Quick fixes usually require good guys. The Development Wizards of the company, instead of doing new things, are mending and patching projects…
The Business Pressure
The best developers should start the projects. And the worst should correct mistakes or add features, as these are a great ways to teach developers not to do mistakes. Sounds simple and easy? It is not.
A sad reality of business world is that the best developers are allocated to solve the problems of income generating products. It remains the the worst developers the very difficult task of starting new designs. It seems ridiculous? It is not. It does makes a lot of sense, to be honest.
A company should be profitable to survive. Then imagine yourself as the Development Manager and the company’s main product calls for a new feature. This will bring in new business. The whole company will push and do lots of pressure until this new functionality is ready. With or without preparation as manager, it does not seem obvious that one should allocate the best resources? If so, who will make the new projects?
Yeah. It is easy to understand the problem. Sometimes it will be easy to solve. And when it doesn’t?
Mitigating the Problem
I realized throughout my career that if I was to leave developers by themselves they would work according to their own standards. This way, if we have 10 of them, we will have 10 standards and 10 ways of working. Except for a small rarity developers, most designers will not bother to align a common way of working with their peers.
As a development manager, I always sought to encourage this interaction and the results have always been very satisfactory. At first, all developers got a little upset by having to adopt the group’s working ways. But when someone inherited a task from a colleague, they recognized a similar job with his. The bad feeling dissipates in no time.
But how does that help? It greatly increases the team interaction. Thus, the weaker developers could get instant help from the best ones; and learn from them. The best could influence the new systems from the beginning, while focused on the urgent tasks. And the urgent tasks were still crafted masterfully in favor of new business for the company.
People
In short, no implementation, over the lifetime of a scalable product will be free of, let’s say, questionable technical solutions. Developers can not afford to be purists and believe in the silver bullet. Entropy increases as more things are added to a product.
However, a product that is nicely planned tends to suffer less with entropy. It remains manageable for much longer, perhaps even when there is no more market for the product no longer more features or bug fixes are requested. A system must be planned until its lifetime is over.
Golden Rule: more important than the things that a developer does are the things that he defines.
Finally, everything always comes back to the developer. The more he interacts with his peers, the better the quality of the things he does. Rule: more important than the things that a developer does are the things that he defines.
I always say (and I’m never tired repeating it) that development is a social activity. When I opened this article talking about stupids, I say that stupids are those who refuse to understand the social part of their work and its influence on large systems. Stupid are those who think they can do complex things alone. Now that’s a defect by definition. The rest is simple design error, therefore easy to fix.
