I am frequently reminded of the quote, "In a hierarchy every employee tends to rise to his level of incompetence," from The Peter Principal. I am reminded of this as I watch technical people get promoted into areas of management. will not subject you to a handful of examples of managers that I have run into who were promoted to (or above) their level of incompetence.
Recently, I have seen crystal clear examples where this occurs even within software development. Someone does not need to go outside of software development and into management to be promoted to his or her level of incompetence. There are plenty of opportunities to be promoted to a level of incompetence within the software development ranks.
Software development is often viewed as having one constant path from the junior programmer to the most senior architect. This is not, in fact the case. Each role is not just a more complex version of the last. In some cases the skills and perspective required for the next role are radically different than the skills and perspective of the previous role.
Still, many of us need constant feeding of our egos. We want to climb the ladder in the software development hierarchy. I, myself, have to find ways to feed my ego in healthy ways that do not get in my way. Many people feed their ego with promotions to the next level in the hierarchy. They do this whether or not that level is a place where they succeed today or where they can succeed in the future.
Too many people learn too late that they have been promoted into a position that is beyond their current capabilities and beyond their true heart's desire to become effective at.
Keep it simple, stupid
The fundamental rule of any good architecture is simplicity. Good architecture relies upon a few well-used basic principles that are tied together in the right way. The problem with the best developers is that they are good at so many basic principles that they find that they cannot contain themselves to just using a few basic principles.
They may start out with an object oriented design and add in a recursive algorithm for some hierarchy. There may become a need to improve performance so they reach towards tools of moving business logic into stored procedures in the database. The next problem is a way to represent information in a way that is user configurable, so XSLT is added to the solution. Next comes a new programming language and so on. The architecture may perfectly leverage each of the strengths of dozens of technologies making it look on paper to be the best solution to the problem that there could be.
However, the truth is often far from this. The architects, a group in which I include myself, often forget that the developers on their team are not nearly as broadly skilled or even as talented as they are. They forget that not everyone understands how to write a stored procedure. They overlook the lack of XSLT skills on the development team. They delude themselves into thinking that the next technology, practice, or procedure will not make that much of an impact in the learning curve necessary to create the solution.
Further complicating this is that most architects do not view their solution in terms of how it will be supported over the long term. It may be possible to find developers today that have all of the necessary skills, but what about tomorrow? The developers today may be able to understand all of the technologies well enough to develop with them, but will they be able to work with the infrastructure team to troubleshoot problems in the production environment once the code goes live?
The best developers do not register complexity at the same level as their peers. There are more things that can fit into the solution before it becomes complex. This is dangerous because each additional technology and each additional approach creates more opportunities for the solution to fail. The more opportunities that there are for failure, the more fragile and unreliable the solution will be. Obviously, the more unreliable the solution the less desirable it is.
I have a confession to make. Many times I have broken the rules that I have laid out above. In working development projects, as well as infrastructure projects, I have allowed myself to create solutions that were unnecessarily complex because I could.
One time in particular that I recall was many years ago. I was a network manager at the time. We had an AS/400 system, which we connected to our LAN. Because of this we used Token Ring. It was just before the time that the Ethernet adapter for the AS/400 was made available. Token Ring worked well for us until we needed to deal with an electrical problem.
For some rather technical reasons it became necessary to use fiber to connect two buildings. When confronted with a price of $4500 to connect the other building with Token Ring, I opted for a cheaper, Ethernet solution, which cost $2200. The solution seemed fine to me. It saved a few thousand dollars in a very tiny budget.
Sure, Ethernet was a different technology that none of the staff in the company knew. However, it was not that hard. It was a different connector, but it was just electrical signals flowing across a wire. What I did not realize is how different it was. I did not realize that the technical staff would struggle with the solution for years to come.
First there was the difference in cabling. Then there were the special quirks to the arrangement of pairs of wire in Ethernet. Then there was learning about broadcast storms. The learning went on and on. Eventually, because Token Ring died in the market, the company converted completely to Ethernet. Despite this, however, they spent many years struggling with having two different kinds of networking technologies.
Making the transition
Not all of the best developers make poor architects. There is no automatic path of doom when a developer makes the transition to being an architect. There is no automatic path for success, either. The pitfalls are hard to avoid. However, some guidelines can make the process a bit safer.
- Focus on different developer profiles in the architecture. Each developer operates within a level. They have a certain amount of skill that they can call upon. When developing an architecture, pause to think of each type of developer that you will be working with so that you can ensure that the architecture makes sense for each of them.
- Do not think fancy. Think doable. Architects tend to look for elegant solutions, even when elegant solutions are not called for. Architects tend to think in terms of some grand plan, even when there are pieces that do not fit. Focus on solutions that work instead of solutions that are elegant on paper.
- Seek input from others. It seems obvious that an architect would seek the input of others as they are new to the role. However, often times their ego gets in the way and prevents that from happening. Seeking input from other developers and architects is an important part of adapting to the capabilities of the group you are working with.