10 signs you should fire your developers

Good developers are worth their weight in gold, and quite literally so. On the downside, bad software will eventually kill your business. In this article, I will describe - from a management perspectice - ten surefire signs that you're better off firing your developers than keeping them.

At the same time, if you're a developer and you see these signs in yourself or your coworkers, today may be a great day to hand in your two weeks' notice and find a proper developer job. You're doing yourself a favor by taking the first step!

The following list are epitomes of an organizational culture which will eventually result in a steaming pile of garbage that is both worthless and expensive rather than software which lets the company flourish. Systems generated in such a culture are parasites - they suck the very life essence out of everyone who has to deal with them, and the longer you let them fester, the bigger the problems will become.

Ten signs you should fire your developers

#1 - Working 9 to 5

Creative work can't be clocked. When developers always start at a fixed time and always drop the pen at the same fixed time, never taking work home, that's a huge red flag. Sometimes, the best ideas happen while jogging, under the shower or even while playing a game. Most work doesn't happen at work - solutions created exclusively on the clock just plain suck.

#2 - Copy Paste Solutions

Software development is creating new solutions and optimizing existing solutions. By copying and modifying the same thing all the time, complexity grows over time and simple changes eventually become extremely difficult. This way of working is unsustainable, and by the time this becomes obvious, it may be economically impossible to change course.

#3 - Need for supervision

Developers need to think by themselves. When developers only do what they have explicitly been assigned to do, only work when someone is checking on them and outcomes need to be monitored before they can be released, you have a serious problem.

#4 - Closed groups

The world is bigger than we think. When developers dig trenches to the business, can't even give you the name of a single user, much less having a professional relationship with any of them - how can they build the right product? A sense of "stranger danger" where developers perceive every new face as a threat means that they have already lost touch with reality.

#5 - One Trick Ponies

"If the only tool you know is a hammer, every problem looks like a nail".
When developers see technical diversity as a threat, can only work within a single paradigm and start to frame business problems in terms of what they know rather than expanding their knowledge to suit the business domain, you have the wrong people. Combined with a "my way or the highway" attitude, you can be certain that the money you sink into development exceeds the value generated.

#6 - Learning passivity

Knowledge work is all about knowledge. A continuous hunger for new knowledge allows developers to excel in their field. When developers resist new ideas, need to be told when they need to learn something new and shy away from experimenting, they lose their edge - and so does your software!

#7 - Limits to responsibility

Great people care for what they do, and want their work to make an impact. Statements like "Works as Designed", "Works as Requested", "Quality is a tester's job" or a pervasive mindset that users are just too stupid to use the software properly imply that developers have locked themselves into an ivory tower and try to shelter themselves from reality.

# 8 - Frameworks frame thoughts

If there were a standard framework for your business, someone else would be doing it better and cheaper than you could. Be very suspicious when the answer to every question is, "<this framework> can do it", especially when the solution always looks like the framework says it has to. Once developers have a standard of standards for developing new solutions, you know they're solving the wrong problems.

#9 - Enamored with code

Nobody cares what happens "under the hood", as long as the engine runs. When developers esteem good-looking code higher than the business utility of said code, they waste time and money. Combined with an attitude that the code would look much better if it wasn't for constantly changing business demands, you know that eventually, the house of cards will collapse - and your business might tumble down with it.

#10 - Caught in the past

The marginal value of every technology is Zero. Yesterday's great solution is often just barely useful today, and last decade's state of art is today's liability. If your newest technology is half a decade old, and the "never change a running system" mindset pervades the organization, you're riding a dead horse already. If on top of that, developers feel emotionally attached to "their baby" and aren't willing to let go, you'll be stuck between a rock and a hard place.

Toxic culture

Encouraging and reinforcing the behaviours above creates a devastating culture. If you encourage behaviours that fall into any of the above ten categories, you are creating a culture where high performance isn't even possible. You may likewise inadvertently be shaping culture by not stopping these behaviours, not calling them out or just tagging along with them. As such, it's always a people problem, that is - a problem created by management.
You can't close a blind eye to these. You have to call them out, you have stop them, and you have to actively work against them. There's a reason why people do these things - and rarely is the reason that people want to hurt the business or their own career. Explore the root cause, and eliminate it!

Organizations where development works as above are career dead ends. They take the purpose out of the work and make IT as a whole a massive liability. The faster developers leave such a place, the better it is for them. If they no longer have the will to take this step by themselves, do them a favor and help them move towards a better future.

Berlangganan update artikel terbaru via email:

0 Response to "10 signs you should fire your developers"

Posting Komentar

Iklan Atas Artikel

Iklan Tengah Artikel 1

Iklan Tengah Artikel 2

Iklan Bawah Artikel