I’ve been developing software for over 20 years, and have worked for many companies. During all of that time, I have read countless literature and attended or watched many lectures on what constitutes good software development practices. Nearly all of the applications I’ve worked on have been problematic to say the least. Anti-patterns, tech debt and cut-and-paste feature enhancements abound. Why is it that with all of this good material on best practices it seems impossible to find a work environment that actually follows them?
A short list of reasons why this is so based on my experience is as follows:
1.) Too many people
Many companies simply have too many people working on a single given codebase. It’s a given that the more people you add to any organization, the easier it becomes to miscommunicate. Bringing more than two or three people to the exact same conceptual understanding with a clear articulation of the reasoning that lead there, is extremely difficult. Try doing that with 50+ people, accounting for all of their differences in talent, motivation and so forth.
In some places I’ve worked, the sheer size of headcount is a motivating force for management because the bigger the org, the more prestige and the bigger the funding. This is poison.
2.) Organizational mis-alignment
If your software is a big, tangled blob then chances are so is your organization. Perhaps not so for the overall structure of the enterprise, but definitely so within the org tasked with building and maintaining the software.
3.) Relentless feature pressue
No software implementation is perfect and even if it were, techniques change over time such that what might have been the best solution yesterday is now obsolete. Tech debt is a constant factor in any application and the debt must be paid. However, if business and technology are not integrated in your company, then business will drive technology with an endless feature parade of varying merit. All of these features will be “must haves” and will supersede engineering efforts to address tech debt because the business brings in the dollars and technology is supposedly just a cost center. And several years down the line when the application is rotting from within, the business will blame technology for not doing their jobs correctly.
Incidentally, I firmly believe the time has never been better for internal software teams to become a value center within their enterprise, but that’s another topic.
4.) Poor hiring practices
I understand that job openings need to be filled as quickly as possible, that they are tied to quarterly budgeting and may be withdrawn if left open too long. But if we accept that too many people in the org causes communication friction and conceptual fuzziness, why should any company be in a rush to hire? Hire the right people, not just a body to fill a seat before the job req goes away at the end of a quarter. If the person you hire in a pinch is a full-time employee, it could be incredibly difficult to get rid of them depending on where your company is located should they turn out to be a barnacle. If your company uses a “contractor funnel” from which to source full-time hires, that’s a whole other set of problems.
Companies where I’ve worked that bring in contractors en masse don’t realize that a lot of those contractors suck. Now you have someone sitting in a chair banging out code who really doesn’t care about your architect’s or team’s conceptual understanding of the domain, or adhering to good implementation practices. You might say, “Well, we’ll just fire them then.” Yeah, right. I’ve seen absolute idiots keep their contracting positions for up to 2 years for reasons I can only wonder at. Meanwhile, I and others like me have to clean up the stink they smear everywhere. And the best is when this lackluster contractor is popular on a personal level so they get hired! Now what do you do?
***
Given all of that, you might be tempted once a week to give your notice and go find another job – a job at a company where business and technology are more aligned. A job at a company with sharp people who are vigilant stewards of their code quality, and who understand how to use the right architecture to solve the right problem.
I’m here to tell you that such an environment is extremely hard to find. I have only worked for one company in 20 years that I would say came close, and that was back in the 90s dot-com boom when everything about internet software was new. Your chances now of finding an environment devoid of adversarial relationships between business and technology (not to mention IT/application support), and where the comparative number of excellent developers to human ballast is high are not good.
What is an aspiring software developer to do in such conditions? Teased with visions of a better world, we look out and survey the job landscape rich with tales of amazing productivity, job significance, camaraderie and lush compensation. Perhaps we make the jump, only to find ourselves dealing with the same problems we thought we’d left behind.
My advice to you is this – You should not leave your current job unless it’s for one or more of the following reasons:
- You are going to start your own company or otherwise go into business for yourself
- You are completely unable to advance an agenda of your own within your company. This potentially means using back-channels and asking for forgiveness later.
- Politically, you are at the mercy of those around you who are less competent and seek your destruction because you outshine them.
- Your employer expects you to devote every waking moment and ounce of energy in order to be “successful”
- You have found another company that will give you a material advancement – whether in pay, title, equity, whatever – or that more aligns with your interests as applied to business or technology. Just realize their codebase is probably also terrible.
Messy software by itself is no reason to leave a company because it is so ubiquitous in the industry. I wish that were not so, but it is.
