Brief description

A project should be implemented on top of solid foundations. There’s a common mistake in many software projects which consist on learning a key technology from scratch as the project is being implemented, and this management pitfall has big long-term issues: an horrendous technical debt.

What causes it

Probably a mix of two things:

  • Developers aren’t always honest. Usually many developers go beyond their limits at some point, and they won’t accept that they might need mentoring and/or training to evolve on some new technologies.
  • Management hires the wrong talent intentionally. Either because management wants to reduce costs in the short term or because of wrong other assumptions. Exceptionally, it happens because of just bad luck.

The problem

Software development requires a wide range of skills and good amount of knolwedge to implement successful projects. In the other hand, not all projects can be funded to hire the right professionals for the job, and mostly entrepreneurs won’t desist on their goals anyway. Also, this isn’t just a problem happening in startups or small businesses, but it also affects medium and large sized companies as resources can be based on planning mistakes.

Those facts configure unbalanced business environments where the expectations are too high while there’s no much love on ensuring that things are being made by both the right professionals and the solution is done right.

And then the problem arises: hire people which sound good, give them the challenge and let them learn key technologies from scratch as they develop to architect the solution. Management sells out that a good teamwork environment is better than hiring experienced professionals for the the job because persons go first, which is in turn a falacy to hide that their goal is reducing costs. Is experience and deep knowledge an ingredient to create hostile workplaces? Really?

The problem goes further as developers play an important role on increasing it. Current state of software development says that most developments are done on top of development frameworks, hence it’s easier to get a result in less time, but it’s also very easy to get a good surface hiding a complete code mess.

Software development isn’t a trivial task. As a project grows there’re certain decisions about its architecture that can be evil, producing what many calls technical debt which ends up in increased response to change times, maintanability nightmares, business reliability issues, and what’s worse: the ones which created that messy software get absolutely depressed because there’s no more room for R&D as their routine is based on fixing bugs and implementing unplanned features, thus they leave from the company to start the vicious circle again in a new company.

The solution

There’s no single solution to overcome the whole problem as its a combination of bad synergies and wrong assumptions, but it might be summarized as follows:

For management

Projects should be scaled based on available bucket. Human effort has costs.

Time-to-market and earnings are important, but more important is creating sustainable and fair businesses. That is, the end does not justify the means. There will be always professionals willing to work for less, as many as ones wondering why training and mentorship aren’t an integral part of successful companies and projects.

Avoid to work with super heroes capable of being champions before ever winning or losing one or more fights.

Why don’t you hire experienced people to revert the negative vicious circle into a more positive trend? Those who are already experienced professionals shall offer their knowledge to those who are just starting the race.

Therefore, programmers don’t learn a key technology from scratch as they develop a project, they should be guided to perform a exhaustive R&D and some proof-of-concept projects, and indeed get training.

For developers

Developers aren’t heroes. They should internalize that a key technology can’t be mastered in 2 days (neither a month!). There’re paradigmatic and architectural principles that demand time to handle them properly.

Nowadays there’re tons of frameworks, libraries and utilities to solve a lot of problems, and these are like using a medicine without prescription. Probably there’re some cases where someone may be fine using antibiotics, but the more antibiotic auto-consumption happens, the more resistance bacteria have to them. That is, many diseases are even more problematic than ever.

The medical case may be also applicable to software development. Everyone’s feeling like a super hero as 10 hours of reading documentation about the new and fancy top trending development framework let them create applications and systems like champions.

The big issue with this behavior is that frameworks are created on top of proven software designs, and while these give a lot of work already done, they still need some love to create good solutions. That love require experience and a medium understanding of what’s going on behind the scenes (i.e. kwnoledge, know-how).

Sadly, developers tend to be narcisists and they don’t look for assistance from others who can even be technical mentors: they might even discuss a decision… This is terrible!

Honesty, modesty and being a true open-minded individual turns out that it should be the decisive requirement to build teams that practice true teamwork. Hence, when developers are lacking some knowledge or skill, they should be transparent and they should have require someone train them or at least review their conclusions before coding anything. Or in the end, even desist to continue on the project if they feel that won’t be able to handle the project at the required level. There should be enough opportunities during their professional career to satisfy past failures.

Also, individual software design mistakes may be the headache of other profession colleagues that might work on a given project, and we should work to get projects to success and also be yet another grain of sand to make better workplaces.

Finally developers should be able to find a balance between learning, R&D and implementation effort to assist businesses in their goals. Either earnings or knowledge’s hungry doesn’t justify the means. Businesses are required to get benefits to survive, and employees need a salary. Also, they should be brave to say no when something is unrealizable even when there’s a pressure to do it either way.