7 realities of software development that your boss doesn’t understand
Developers are more than aware that certain aspects of their job are considered unchartered territory by their boss – but what about the parts of software development that they shouldn’t be so clueless about? John Sonmez has put together a comprehensive list.
As blogger John Sonmez has said, even the best bosses don’t understand what you’re doing when it comes to software development. Sound familiar?
1. Technical debt slows down projects immensely
As Sonmez notes, managers and other non-technical staff often don’t understand that a desire for higher productivity will inevitably lead to a drop in quality, which goes hand in hand with the accumulation of technical debt.
To ensure you’re not killing the goose that lays the golden eggs, you have to keep an eye on things. According to Steven R. Covey, this means keeping production and production capacity in good balance.
2. Estimates are worthless
The question of the sensible or ‘nonsensical’ case of cost estimates has recently been a hot topic for JAXenter. The same goes for Sonmez – according to him, estimates that go further than 2 hours into the future are worthless. This is quite simply for the fact that, since almost every project represents virtually uncharted territory, the unforeseen can constantly happen – a circumstance that cannot be eliminated.
If supervisors nevertheless insist on estimates, Sonmez recommends that developers should either try to convince them of their folly or insist on breaking down tasks so that the estimates only cover short periods.
3. You can do it quickly or properly
It’s the same old story – a boss says to a developer that a certain task needs to get done faster. The result is likely to turn out, with almost absolute certainty, like crap. Because many programmers take shortcuts in stressful situations, the work produced is therefore detrimental to quality. A thorn in the side of Sonmez are the so-called “cowboy coders”; completing their work at breathtaking speed, but in doing so creating a big mess, leaving technical debt for others.
A tip Sonmez shares for all those devs having to deal with bosses unfamiliar with the phrase “You can do it quickly or properly”: highlight the statistics that show that the ironing out of bugs is significantly more expensive than their prevention.
4. Some developers produce less than zero code
Some developers can cause more harm than help in teams, with Sonmez saying that every line of code they produce can create problems instead of solving them. But who wants rat out on a fellow employee? Sonmez is aware of this problem, and although it might be hard, he insists that this is the only way to proceed if a team member is pulling down the rest of you.
He says that if you don’t report blatant incompetence, you can consider yourself incompetent as well.
5. Better equipment is the cheapest investment in productivity
A 5 year old computer, no second screen… Sonmez is sick of the stories developers tell about their cheap bosses who won’t fork out for a better setup. Mindful of the mostly above-average salary that a programmer makes, new equipment is actually a negligible cost point – it’s an investment that quickly pays for itself.
Even if a developer saves just half an hour of working time per day by using better equipment, the hardware has become a good investment. Unfortunately, says Sonmez, you cannot do more than insist on the need for better hardware in order to convince your boss in most instances, or look for another job with a more astute supervisor.
6. New technologies are generally less risky than you think
In earlier times it was a legitimate fear of senior management that a framework yielded rare updates, with open source not being especially prolific and official support drying up if the company decided to pull the plug. Nowadays there are frameworks patched in parts on a daily basis, and many of them are open source.
On the contrary, today it may be more dangerous to cling to the views of old, when holding onto an old version of a framework or library can introduce certain vulnerabilities. Making the switch is often the smarter choice.
7. Business analysts and project managers do… nothing
This could be considered a bit of a stretch, but Sonmez believes that both business analysts and project managers are useless. The former are superfluous, since direct contact between the customer and the developer is significantly more enlightening on both sides. And the latter are usually just in the way if you’re operating in an Agile working environment.
How do you get the boss’ attention with regards to this fact? By clearly defining how an Agile team should operate and what roles are needed.
Are there other things that should be added to this list? Let us know in the comments!