This is a, unfortunately, a classic mistake. It is illogical, but I’ve seen it happen so many times.
Step 1: Create a project where a new design is needed from scratch.
Step 2: Management puts mid or low-level engineers in charge of the design.
Step 3: The senior engineers are left scratching their heads.
Step 4: The project a) fails or b) gets re-designed by senior engineers making redundant months of work
I have two recent examples. First, our company wanted to design a new proprietary communication protocol api. Essentially replacing an existent client/server API that is big & bulky, difficult (but not impossible) to extend, and slow in some fast path areas. This included the client and server APIs as well as the protocol itself. Sounds big, right? This would touch every application group in the company. So why not get some mid-level engineers to work on it! That’s just what happened.
They came up with a design that neither solved any of the issues with the existing API nor any compelling rationale to the design flaws senior engineers later discovered. After a couple months of design work the team held a design review meeting with the senior engineers company wide. It was not pretty. Their design was confusing, immature, and, most importantly, failed to solve any of the problems with the current API. The seniors emplored management to either have the team cut back their focus — they could have worked on the three subproblems (client, server, and protocol) independently, fix the existing API by evolution rather than revolution, or turn over the reigns to engineers who had more experience.
These suggestions were not heeded. 7 months of wasted work go by and the team finally realizes they can’t fulfill the design implemenation. They decided to kill the project and go the evolution route. After that meeting, the senior engineers were left shaking their collective heads. I heard many a “didn’t we say that months ago?” in the halls.
The second example is a team gathered to design an automated testing framework. For some reason, our company had never gotten automated testing going before. The need was suddenly deemed from on high that this was necessary for every product before any new releases….go!
The team put together was several junior software engineers and (only somewhat technical) quality engineers. Sounds like a disaster and it was. Similarly to our communication API example, designs were done and meetings were had. Flaws were pointed out — too many layers, inconsistent, nonsensical, not extensible, too much abstraction, you name the design mistake it was in there.
8 months went by and the project never really got anywhere. It was started to be redesigned by senior engineers that just got so frustrated they weren’t being listened to. I left before I could find out how the two approaches panned out in the end.
In reviewing those two examples, I’ve have theories as to how they occured and how mid-sized software companies can avoid these mistakes. In the communications API example, the mid-level engineers chosen were held in most-favored engineer status by management. In reality (obvious to all the seniors), these engineers were hard workers but simply lacked good design skills and experience with from-scratch implementation.
The testing framework API example happened because management heard “scripting language” and took that to mean “not as difficult as real code.” In reality it it not the language but the scope and breadth of the effort. This framework required real design skill as it had to work for many use cases across multiple products. Most importantly, though, it touched every single product.
It may very well be boiled down to underestimation in the effort and overestimation of the design teams skills. The lesson here is to always assign far-reaching or complex design roles to your seniors. For less complex designs, don’t let the juniors fly blind. Regardless of the design scope they will most likely need senior guidance.
One more lesson is that engineers love design so if you think a senior wouldn’t be interested because it’s “a scripting language” think again…at least, ask them first.
