A simplistic idea started spreading for the past years in Romania, and I’ve met it to a lower extent in other European countries as France, Germany, UK, etc. Companies noticed they have a developer crisis. The simplistic solution: the universities and the industry should produce more developers.<\/p>\n
I believe this solution to be completely off the mark. Here’s why.<\/p>\n
We don’t have a developer crisis, we have a crisis of accidental complication<\/p><\/blockquote>\n
Technical Debt<\/h3>\n
I’ve been in enough companies and seen enough code to know that most often the code is too complicated for what it tries to achieve. Complicated code leads to poor estimates<\/strong> because programmers cannot predict they will need to change one thing in 50 places instead of one. Complicated code leads to bugs<\/strong> because programmers don’t understand the code, and they use the “change and pray nothing breaks” method.<\/p>\n
Faced with these issues and with the growing pressure due to them, managers decide to hire more developers. More developers write even more code<\/strong> that’s harder to keep under control, so complications can further increase. It’s a feedback cycle that keeps maintaining itself until one of a few things happen:<\/p>\n
\n
- managers decide to cut off on technical debt<\/li>\n
- a few developers learn how to reduce complication and start doing it<\/li>\n
- the project ends (typically with a rewrite in a new cool technology that solves the problems)<\/li>\n
- the project is downsized<\/li>\n<\/ul>\n
Feature Creep<\/h3>\n
Agile \/ Lean were supposed to end feature creep. It didn’t because we are all humans. Feature creep only ends with a shift in mindset: IT is the business of solving problems, not of writing code<\/strong>. What’s the difference? Let’s take Scrum as example.<\/p>\n
Scrum is too often implemented like an iterative version of a fixed backlog, because of course all the features must be implemented. This is the view of “this is the scope, we must do it and that’s it”. It obviously leads to feature creep.<\/p>\n
The alternative is to gather the problems users are facing and then ask 3 questions for each of them:<\/p>\n
\n
- What is the problem?<\/li>\n
- What’s the simplest solution that could solve at least a part of the problem?<\/li>\n
- How can we implement this solution as simply as possible?<\/li>\n<\/ul>\n
Once the first solution is implemented, get feedback from users to see if it’s good enough. If not, add another layer. And so on. Who knows, you might realize the problem is not real. Or not a priority. Or you might get away with a partially manual solution etc.<\/p>\n
The second way follows the agile principle “maximize the work not done”<\/strong>.<\/p>\n
By the way, when is the last time you’ve deleted a feature from your product?<\/p>\n
UX Accidental Complications<\/h3>\n
I’ve started with technical debt, but complications really start from the UX. If your UX is more complicated than it needs to be, the code will be more complicated, and this will lead to feature creep and technical debt.<\/p>\n
One simple example is the option dialog you find in many products. Try to replace the options with sensible defaults and only add options when enough users complain. Even then, question the need for options first. Why? Because your users will be confused by too many options. Because each option in the application can translate into hundreds of if statements in your code. Because this increases complication.<\/p>\n
Another example is in user flows. If you can remove a step, do it. If you can remove a decision, do it. These techniques might improve usability and reduce technical complications. You can always add later a new step or a new decision or an option, once enough users have asked for it.<\/p>\n
Process Complications And Impediments<\/h3>\n
Finding simple solutions is very hard<\/strong>. It requires a level of focus that reaches the cognitive limits<\/strong>. It requires collaboration, trust and good communication<\/strong>. It requires appropriate tools<\/strong> for the job.<\/p>\n
These things are hard to achieve, and very easy to destroy. Want to destroy focus? Add many meetings. Want to destroy trust? Add innuendo and arbitrary rules. Want to destroy communication? Add verbal aggression, too often used by technical people and by technical people turned managers. Want to use improper tools? It’s easy, there are hundreds of them.<\/p>\n
I often run a workshop called Value Stream Mapping. Value Stream Mapping looks at the company processes in terms of value flowing through from beginning to end, and computes the efficiency of the flow. Not of the people, of the flow. Whenever we do it at company level, the results are staggering. The most common interval for the efficiency was 5-15%<\/strong>. This is frightening, but also great because it shows the huge potential for improvement. It’s possible with a few changes to double your efficiency. You just have to want to make them. That’s the hard part.<\/p>\n
<\/p>\n
A Solution?<\/h3>\n
We don’t need more programmers<\/strong>. We need better programmers<\/strong>, able to find the simplest solutions and to recover legacy code. We need good UX designers<\/strong>, able to solve user problems through simple flows. We need good Product Owners<\/strong>, able to switch from the mindset of “we need to implement this feature” to the mindset of “what’s the simplest solution for this user problem?”. We need to pick the best tools<\/strong> for the job, instead of picking the most complex tools on the market. We need to remove impediments<\/strong> and improve our value flows instead of making sure everyone works 100% of the time.<\/p>\n
We don’t need more programmers. We need a different mindset. A mindset that connects Lean thinking, Agile thinking, UX and Usable Software Design<\/a>.<\/p><\/blockquote>\n
<\/p>\n