Archive for January, 2010
I strongly believe that there are only 4 types of programmers, and that some types of programmers are simply not compatible with others. To prove my theory, I first need to introduce what I believe are the two main metrics that define the way we approach coding, planning and sophistication.
- Planning: The planning metric measures how much time we expend planning before implementing anything.
- Sophistication. The sophistication metric measures how complex our implementations are. The more sophisticated they are, the more extensible and customisable, but also the more complex. In the other hand, low sophistication, (called pragmatic from now on), prioritizes simplicity over extensibility and customisability.
Taking into account this two metrics, it is easy to deduce that there are mainly four roles that a developer can take to in order to do his/her job; these roles can be appreciated in the following matrix.
The previous matrix probably is not going to raise anyone’s eyebrows, is pretty obvious, but what stroke as a revelation to me is when I realized that developers tend to be only comfortable in one of the different 4 axis of this matrix, and that’s what makes the 4 different types of programmer: The planner, the action hero, the pragmatic programmer and the sophisticated programmer.
The planner is the type of programmer that prioritizes planning, in the roles matrix is comfortable only in the first row. As a planner, he might have some preferences about being sophisticated or pragmatic in the designs, but will be open for discussion, in the other hand; the planner will never give up planning up front.
From my experience, I would say that planners are mostly old school developers, some recently graduated student, and people with waterfall background.
The action hero.
The action hero is the type of programmer that prioritizes getting things done now, in the roles matrix is comfortable only in the second row. As an action hero he might have some preferences about being sophisticated or pragmatic in the designs, but will be open for discussion, in the other hand, the action hero will never give up the getting things done now.
From my experience, I would say that action heroes are mostly extreme agile developers, technical gurus, and junior developers.
The pragmatic programmer.
The pragmatic programmer is the type of programmer that prioritizes simple implementations, in the roles matrix is comfortable only in the first column. As a pragmatic programmer he might have some preferences about planning up front, but will be open for discussion, in the other hand, the pragmatic programmer will never give up keeping the implementations as simple as possible.
From my experience, I would say that pragmatic programmers are mostly agile developers, and lazy developers.
The sophisticated programmer.
The sophisticated programmers is the type of programmer that prioritizes extensible, customisable and standard implementations, in the roles matrix is comfortable only in the second column. As a sophisticated programmer he might have some preferences about planning up front, but will be open for discussion, in the other hand, the sophisticated programmer will never give up keeping the implementations as sophisticated as possible.
From my experience, I would say that sophisticated programmers are mostly technical gurus.
Why can’t we be friends?
Have you not ever wondered, “how’s possible that always that I talk with this other programmer I get irritated?” To understand why, it may help you to ask yourself what type of programmers you guys are, because, I’ve found that programmers that doesn’t share any role in the role matrix, are simply not compatible with each other. Practically this means that the following two combinations will have a hard time collaborating.
- Pragmatic programmers and Sophisticated programmers
- Action heroes and Planners.
Programmers of the same type are likely to collaborate better. Programmers that share only a role will have to discuss more frequently but are likely to get to agreements.
So, what’s the best type of programmer?
The best type of programmer would be the one that can switch role base on a case-by-case basis, but frankly, I haven’t met any yet, as I said previously in the article, all the developers I know are only comfortable in one of the axis of the roles matrix, which is what determines their programmers type.
I also believe that during the development of software, there’s a moment where each of the different roles is necessary, that’s why I believe is good to have a team where the programmer types are balanced.
They are evil!!
It always comes the time in almost every project when some difficult task needs to be performed and so the team will ask themselves: “How are we going to implement it?” is usually at this stage, after several meetings, brainstorming and debates, that an approach is decided, and a proof of concept is arranged… And that’s when the team fails in realizing that they are about to waste their time.
Proofs of concept look ideal on paper; they are supposed to be an excellent mechanism to validate the approach that is about to be taken in the project, but the reality is that they are not, and that’s what I would like to talk about in this article.
Why proofs of concept are bad.
- They don’t tell you if you are about to do the right thing, they only tell you if that specific approach is feasible. Most of the times, is not about if what we are proving is valid or not, is about how much overhead there is in maintain or integrate what we are proving, but proofs of concept are usually very limited telling us what these boundaries are.
- People who sponsor a proof of concept get emotionally attached and loose their objectivity. After a proof of concept, a decision needs to be taken, but the people who sponsored the proof of concept, because their ego, will have their objectivity affected and will push to have the proof of concept accepted no matter its output.
- Proofs of concepts tend to be very specific and focused; they leave outside of the picture many critical areas that need to be proved. For instance, if proving a reporting tool: The proof of concept may be focused in generating some particular type of report, but it may leave outside of the picture some other areas, as the integration of the reporting tool with the application being developed or how customizable the generated reports are.
- Designing a good proof of concept requires a full understanding of the domain. To design a good proof of concept, is important to identify upfront what are the different risk areas, so they can be proved, but for most situations that’s impossible, so is very likely that after adopting some approach the team is going to hit some unexpected limitations on the approach.
- Proofs of concept distract the team from the main goal and make them switch to an R&D mentality. Teams doing proofs of concept usually switch to a R&D mentality, with a R&D mentality is very easy to focus in gold platting the application.
All this disadvantages may translate in the following four real major issues in your project.
- Waste of time
- Technical debt
- Fail to deliver all the requirements.
- Integration issues.
How to avoid Proofs of concept
These are my 5 key practices for avoiding proof of concepts
- Find the next baby step. Usually when a proof of concept is kicked off is because the team fails to split the biggest problem into smaller issues. Tackling the smaller issues one at a time is easier and is likely to produce a more integrated solution.
- Keep it simple. Is usual to find proofs of concept to validate at the start of the project how the latest technologies, frameworks… would fit in the application, but I wouldn’t even consider them, I like to start simple, and if necessary add them as we go. I think adding them upfront can become a huge risk factor to the team as they introduce new learning, complexity and integration factors into the project.
- Just do it. When a team is stuck, I find that the best remedy is just find what the next baby step is and implement it.
- Work several options in parallel. Sometimes is just impossible to determine in what direction the next baby step should be, for these occasions just work in parallel all the different solutions. The overhead of working in parallel is paid back early in the project because it will be very clear what solution is the most adequate.
- Delay decision for as late as possible. The general rule of thumb for the whole article can be resumed with the lean principle “Delay your decisions for as late as possible”, find baby steps, work on parallel… but don’t commit to an approach that may cause your project to fail.
Micro optimizations are one of many different bad practices that can be found in a project.
Micro optimizations are bad responses to potential or real project issues, they are created when the team fails to identify the root causes and instead they address the consequences, this usually happens because:
- Urgency. Not enough time and resources are used to analyze the issue.
- Experience. The patch strategy is always been followed.
- Fear. Sometimes people know what the root cause is, but they are afraid to mention that.
Micro optimizations are bad because:
- They switch the focus of the team from the big picture, they provoke the “Can’t see the forest for the trees” effect.
- They provide partial feedback.
Micro optimizations are usually implemented as check lists, metrics, reports, documentation or some sort of paper work that needs to be approved in order to move forward.
Some common scenarios of micro optimizations that I have myself observed are:
- Because of the high rate of defects, the team decided they had to freeze the development from time to time and wait for QA to pass complete regression tests. This turned out to be a micro optimization and didn’t help at all. The root cause for the high rate of defects was that the source code quality was very poor, which in turn, was caused by a complete lack of experience and knowledge on the team on the technologies used for that particular project.
- Because of low productivity, management decided to hire more people for the project. Again, this turned out to be useless, the root cause for this issue was that development and product owner were not collaborating as they should, and as consequence, development never understood what was really required by the business.
- Because of poor performance, the team discovered that the bottleneck was on the messaging layer, so they decided to expend lots of money in a commercial solution that delivered better performance, this turned out to be a micro optimization and the performance issues came back. The root cause was that the overall architecture was poorly designed.
To avoid micro optimizations, focus always in the big picture, not in the details; use an out-of-the-box mindset. One helpful, very well known and very simple technique to avoid micro optimization is “the 5 whys technique”, this technique is better demonstrated with a sample.
The team only deliver half of what it was expected for the deadline. (The issue)
- Why? They didn’t have enough time
- Why? They had too much work
- Why? They failed to estimate how much work they could take.
- Why? They thought that the required activities to complete were simpler.
- Why? The requirements were not detailed enough.
Avoiding micro optimizations doesn’t mean that the aspects they would usually be focused on, as: performance, punctuality, code coverage… are not important; it means that they serve to a higher purpose.
The biggest effect on moving away from micro optimizations is that you are likely to find that your main issues in your project are not technical, so probably you may want to take a complete new approach on them.