Imagine that you have a board in front of you with a series of holes. Each of these holes are different shapes and sizes. In the pile to the left of you is a is a set of pegs, of all different shapes and sizes. Your task is to fill all the holes in the board.
To complete this task you would probably analyze each hole, get a feel for its size and shape, possibly make some measurements and take some notes. You would then go to your pile of pegs and find the peg that most closely matches the hole you have analyzed. Maybe the peg you find doesn’t fit perfectly, but it fits well enough to plug the hole. Accomplishing this task may not be easy, but with the plethora of pegs available to you there is a good chance you will finish it.
Now imagine if you were given the same task, but were told to use only square pegs. Some of the holes could still be filled, and filled well, but most likely your task would become exponentially more difficult, and you would be left trying to fit these square pegs in round holes.
Software development is problem solving activity, much like filling holes in a board. As software engineers we are presented with a series of problems (holes in a board). We analyze these problems, come to an understanding about how they could be solved, and then go out and find the solution that best solves them (find the peg that fits the hole the best). When mandates are places on the solutions we are to develop, there may be some cases where those mandates are helpful, but more often than not you are left trying to solve a problem that cannot be solved or solved well with the mandated solution (shoving square pegs into round holes).
What do initiatives have anything to do with all this? First, let me say what I mean by an “initiative”, it’s a strategy to fundamentally improve the quality of the software solutions we develop. Examples of initiatives include striving to become platform independent, moving to component based software engineering, or finding ways to utilize cloud computing technologies. Initiative are positive, awesome things. So why am I calling them out?
The devil of initiatives is in how they are implemented. Too often those making the decisions hear an initiative and interpret it as a mandate, or feel that the best way to achieve the goal of the initiative is to make mandates in support of it. This is completely counterproductive to an initiative. The problem with mandates are that they can overrule the best solution to a problem. If the purpose of initiatives is to improve the solutions we develop, then it doesn’t make sense to build inferior software in support of the initiative.
It’s not just the quality of software that can suffer from mandates. Mandating a software engineer make the wrong design decision in support of an initiative creates frustration for them. It is counter to everything an SE stands for. It just doesn’t feel good. This frustration can affect teamwork. When you are developing a component under a mandate and all you are doing is churning out kluges in attempts to find a way to fit that square peg into that round hole, more likely than not the members of your team will have a hard time understanding why you aren’t done building it yet and why it isn’t of the highest quality. You begin to hold up their progress, and then they get frustrated with you. Suddenly everyone’s opinions of each other begins to drop, and you are left with a dysfunctional team.
So, what’s the solution? We need to understand initiatives and stop the mandates!!!
The best way to view an initiative is as a green light to extra devote money and resources in support of it, but only when it makes sense to do it. For instance, if you have an extremely performance sensitive application, and the initiative is to move development to python, don’t mandate it be written in python! C is far better suited for performance sensitive applications. Bottom line, you can achieve the goal of an initiative by allocating resources and money towards the pursuit of it, not mandating that everything be done in support of it.