Anti-patterns and Malpractices in Modern Software Development (2015)

I generally agree with the author, but as a software developer, I try to stay much less emotionally attached to the end-result. If I have concerns about the long-term stability and viability of a code base, I'll raise my concerns with the project manager or whomever's making the decisions on what to prioritize. But if they don't want to, that's their prerogative. They're higher on the chain of command than I am. I'm certainly not going to lose sleep over it. When the house of cards does come crashing down and it takes two weeks to add a simple feature due to tech debt, or worse, some bug surfaces that takes down a production deployment and takes more than an hour to fix, my ass is covered. I have an email trail raising concerns that went ignored.

I cannot disagree more strongly with this article and the attitude behind it. I mean, look at each of his points in turn:

1. His first two points, stripped of the irrelevant polemic, are the complaint that software is meant to help the business meet its goals. Well, obviously it is. Very few people are paid to build software as artistic expression; that's for personal projects. Software that doesn't meet a business goal is bad software, no matter how elegantly designed.

2. His third point is that when you're in an organization staffed by people with their own personalities and goals, you need to be able to communicate and negotiate and engage in all kinds of human interactions. People who call this "politics" dismissively, as the author does, and think that it is intrinsically bad should never have a job where they have to interact with people; stay a low-level code-wrangler.

3. His fourth point is... well, honestly, it's that he hates his job. Sorry. Most people don't, though. If I were him, I'd look for a different role.

4. His fifth and sixth points are that if you work on a team, you also have to work with teammates, who will have their own personalities and goals and interests, and you'll need to be able to communicate and negotiate and engage with them. Um, yeah. If you aren't willing to do this, you're going to be a terrible teammate, and this guy sounds like he would be one, with all the griping he does about the coworkers he hates.

5. His seventh point is about collective code ownership, which is about treating developers as collaborating equals rather than letting one person on a power trip control everything. This upsets him, because he's the guy on a power trip and he wants to control everything.

6. His eighth point is that management methodologies exist. He seems to think this is self-evidently terrible, rather than considering that changing management methodologies can make a huge difference to the success and happiness of a team, and that agile methodologies are much better than old-school command-and-control waterfall stuff in a ton of ways.

7. His ninth point is that you're not cynical enough, because you don't hate everything already, and he does, and that makes him a better person, and you should also join him in hating everything and everyone.

This is literally toxic advice. Do not take it, and if it sounds reasonable to you, it's time for some soul-searching.

Software development is hard. The first few years out of uni as a software dev can be awesome (if you're lucky enough to land a decent job)... Fast forward 10 years and you will be mentally exhausted.

If you were hard working, ambitious and curious, there is a point (for me it took about 12 years after I started programming) when you realize that you know pretty much everything that there is to know about software. Anything that you don't already know is just tedium.

Being a software developer is tough, but then again, most jobs are. I do think that among the jobs that require advanced education, software engineering is definitely one of the toughest psychologically.

Software engineering damages you psychologically. The best software engineers that I know are also the most cynical people I know - All atheists, nihilists and pessimists (and sometimes downright depressed).

Being a software engineer can subject you to the full, ugly complexity of life.

The part abou collective code ownership hits way too close to home. I've probably spent more time fixing existing functionality broken by others recklessly implementing new functionality than implementing anything new myself. Guess what looks better to management though?

I started working on contract for a large software corporation about two years ago. At first it was very disorienting but I slowly began to "learn the ropes".

One of the first, somewhat shocking, things I realized was that if I were to somehow rewrite the project code in such a way as to reduce the number of people required to work on it, no one would thank me. In fact, people would likely have gotten upset with me.

The folks who lost their jobs wouldn't thank me; the contractor who makes money from their billable hours wouldn't; the company managers wouldn't (their "stake" or whatever would be diminished by having fewer personnel under them); etc...

Basically there was a kind of local optimum: the code had to work and be maintainable enough so that no one looked too bad, but it couldn't work too well, nor be updated too easily, because then people would lose their status, revenue, or even jobs!

The internal logic of the system was mostly unconscious and hugely wasteful. I estimate (and I'm not the only one) that any three of us on the project could start over and reimplement the thing from scratch to feature-parity with the original in three months. (It is not a complicated or innovative thing.) After that, less than half of the current team could do the same maintenance and development. The rest of us could go do something else... But no one is interested.

The "us vs. them" attitude that appears to be underlying this article in my opinion largely is to blame for these problems.

Engineers often don't respect business and look down on management.

Instead of learning to talk and - more importantly - understand the language of business, developers frequently don't care about business requirements at all. Hence, more often than not they're not taken seriously and don't get to have a say about the direction a software product is going to take.

Instead of pushing back against unreasonable requirements or questioning why a particular requirement is even necessary in the first place, many developers resign themselves to acting passive-aggressively and keeping their mouths shut.

Why don't more software developers found their own companies if they're legitimately unhappy about their work environments? Why is it that often companies founded by software developers end up being the worst offenders in this respect?

It's also cherished, enshrined principles like 'reusability' that can lead to over-engineering and consequently both a deterioration in quality and failure to meet business requirements. As an engineer you should always be asking yourself: "Does what I'm about to implement have any merit or do I just think it does? Am I perhaps even just doing this as an exercise of proving how clever I am?"

> The longer-term you can think about your software, the more robust and less costly and painful its development will be.

That's true only if you have experienced engineers from a range of backgrounds. Put a bunch of junior devs on the project, and they'll prevaricate about issues such as "tabs vs spaces".

The whole article sounded too much like a rant. The problem is not "how do you build good software" but "how do you build software that's good enough to generate value, manage technical debt, and still make money?".

The writer has obviously suffered unfortunate environments. Not all environments are this toxic though, but the ones that are eat through your soul in incredibly painful ways.

The privileged few who have not been forced into these situations should take a silent moment, and be thankful of their own luck.

For the rest of us, we'll just have to try to distance ourselves from our jobs, and let our wounds teach us.

this is my favourite part:

>let us consider that being ‘blocked from making changes’ can actually be a very good and necessary thing. It’s something that the senior engineers of yesteryear once had the power to do. They sometimes did it out of spite, yes, but more often to keep code over which they had stewardship from being compromised by short-term thinking. Blockers were put up to ensure that software could be developed at a sustainable pace with the minimum of human suffering involved, and to be used as a check and balance against a management team not in a position to understand or learn about engineering trade-offs at stake.

Every time I've been blocked from immediately merging in my changes I've learned how to be a better developer. Yes there's a few times where it's been out of spite but the majority of the time it's led to conversations that have significantly improved my understanding of the code base and how to approach it and the culture of development at the company.

Have a spine and be willing to say no to plain old bad code.

The problem of sotware is the fact it is roughly an «artisitc work» (hence the IP crap laws) and that there is no obligation of results, hence no warranty to protect the customers.

It is pretty much the wild west of the economy that is fueled on lack of fair law to balance private interests vs public/consumers interests.

I find #3 to be the truest malpractice. I'm getting to the point of becoming an architect at my current company. However, I don't even want the role. Our current team manager hasn't participated in software development in over a decade. It's a hindrance and much time is spent making arguments to actually follow commonly accepted good practice.

I've led phases of design trade-off analysis where the conclusions were essentially forgone at the start. But to humor the disbelievers, we spent a few months testing alternatives. Even after my team had loads of evidence that one design was more performant and durable (with proper patterns used), people in the engineering peanut gallery questioned our methodology, because the results were contrary to their preconceived notions. These guys were leads and architects, who largely seemed unconvinced because they didn't do the work, so it couldn't possibly be correct.

I want to contact my university and tell them to require some sort of "technical rhetoric" class in the curriculum. Appealing to emotion is really the only way to get things done in development when you tackle larger projects. No one believes empirical evidence anymore, nor do they care to follow good practices. It's mostly about leaving a turd behind, cashing out your RSUs after 3 years and letting the next guy worry about it.

The article is incorrect. At least since the 1980's, many many businesses and institutions, big and small, have adopted rigid software development methodologies ostensibly for business reasons and to ensure some form of "quality." In the 1980's, it was structured design. In the 1990's, it was object oriented design. Since the early 00's it has been some vaguely defined combination of Agile, "clean code", test driven development or "it is only unit tests -- it is not test driven development", code reviews, open offices and other forms of extreme micromanagement.

Since the 1980's there have been numerous high profile projects that adhered to each successive software development methodology and imploded, often with rancorous finger pointing.

Business people as well as many software developers are attracted to the will-o-the-wisp that there is a one size fits all magic formula for software development.

Software development is extremely varied. Some projects are small. Some are large. Some, like flight avionics or medical radiation control software, require very high levels of quality and reliability. Others do not. "Quality" means different things to different people and in different situations.

Some software is like the bridge that you never want to collapse. Some software is like the plastic picnic cups that you use a few times and expect to break easily. It depends on the situation, the goals, the priorities which vary substantially and depend on human judgment.

Software developers are varied. What is "readable" code for one won't be readable for another. Perceptions of software designs reflect variations in culture, background, training, personality, and so forth.

There is no one size fits all methodology and attempting to impose one is often costly and disastrous.

Finally someone who speaks the whole ugly truth, and publicly to boot. There is literally nothing in this article that differs from my experience (on the contrary, there are details in its exquisite pessimism I was surprised to find).

Portraying the situation as it is may at least give us a better chance of coping with it. I doubt we can effect more than cosmetic changes.

> leave as soon as your bank account is ready for your next 3 month vacation. I personally consider myself semi-retired since the age of 30. Though it is a life of seeming instability, they’ve done all they can to make long-term engagement unsustainable.

Does not seem like good advice, or taking enough responsibility ("it's their fault I am semi-retired").

In fact, the whole article is a manifesto on how to shift blame onto external sources from oneself—projecting blame onto others and taking as little responsibility as possible.

Eerily accurate stuff ...

Particularly with regard to how DEV is commoditised by management and the inevitable downfall should you choose to fight the good fight.

The money pressure from top simply engulfs technical rationale and makes priorities seem extremely short sighted. And should you want to make technical progress, by all means do by stuffing estimates, but it will be thankless.

> with Ron Paul or Ralph Nader’s talking points? LOL, right? Well, we’re living out their nightmare, one software fuckery at a time.

Just because you know something doesn't mean you know everything. I doubt any top down approach can save you from all the negatives listed in this article, but I believe it could cause them. I believe it more after reading the article too. It's a strange conclusion to draw anyway.

> low-interest rates make it economically nonviable for a company to act in its longer-term interests.

Lower interest rates express a smaller time preference. Ceteris paribus, lower rates encourage risk taking. Longer-term bets are higher in risk, particularly when one considers principal-agent aspects.

Several of my previous team members compiled a list of satire principles for application developments.

Need to flesh them out..

https://github.com/eugenejen/enterprisey_mantras

Aww. Somebody changed the title on the link. :-(

Yeah, it was rude. But it does some up the end of some weeks.

>> "Collective code ownership may be the most pernicious thing to happen to code since the advent of Javascript."

Great quote. I've seen some great code quickly turn to spaghetti under the guise of Collective Code Ownership.

Has there ever been an era in software development when most people are happy with the current practices?

This rant reads to me as if it was written by someone who just spent 6 months adding 37 layers of horizontal abstraction and indirection and a gigabyte of dependencies and yet still failed to achieve their one simple task, only to be shown up by someone else changing the label on a checkbox and achieving the task in 5 minutes. Sure, there are problems in software development, and the article mentions some, but it's pretty much wrong about all of them.

>1) Business Thinking Favors the Short-Term — To an Extreme

Agreed that short-term thinking has problems. But the business environment changes, in some cases quite rapidly. And some software is only needed short-term. There's no business sense in spending a year developing software that can be maintained for a decade when it's only going to be used for 90 days (that is, if the deal goes through - if not, it will be scrapped without ever being used). Nor is it a good gamble to wait 2 years to get a system running when the competition can be building market share within 6 months.

If you're really good at seeing the long-term future, then you don't have this problem because you've already foreseen the winning lottery ticket or stock picks and are already retired wealthy. Right? You think you can foresee all business requirements and all requirements of all customers for the next 10 years?

>2) You Will be Crucified for Not Being a 'Team Player'

This will happen if you're incapable of working with other people. Or if you want to go off on your own and develop something not related to anything that is needed and you can't present any good reasons for doing so. If you want to do something that will make other people's lives easier or make them more successful, and can explain that to them, then the opposite happens. Even in backwards companies.

>3) The Software Architect is a Politician

As much as we all hate politics, the software is being developed for a business purpose and for use by end-users. It's not just a toy for narcissistic developers to sit around gold-plating.

>4) Suffering is the Commodity That you Provide

There is a bit of grunt-work and unpleasantness in software development. That's why it's called a job, instead of "Happy Happy Fun-Time". You're getting paid, you're not paying the company to do this.

>5) Your Peers Won't Support Change

Most will if it's reasonable. If it's as unreasonable as the article, they probably won't, but that's a good thing.

>6) Someone is Always Ready to Undercut You

This point seems backwards. Someone angling for promotion isn't trying to undercut you. Someone trying to undercut you is struggling for survival or trying to reach your level from a lower position. If you're threatened by either then you lack confidence.

>7) The Conscientious are Disenfranchised >Collective code ownership may be the most pernicious thing to happen to code since the advent of Javascript.

People with this mindset are inevitably fired due to their rudeness, hostility, arrogance, and utter inability to produce anything in any timeframe. They seem to believe that their whole job is not to develop software but to prevent the other developers from doing so. Good riddance.

>8) Methodologies Are Management Tools

Yeah, no surprise there, that's what they're for.

>9) You Will Think your New Team / Project is the Exception

More often developers are shocked by the problems that their new team has. They wonder why the team is doing everything the old-fashioned/wrong way and think that they have all the answers and can solve it. Real-world experience quickly solves that. Unless they can't handle the messiness of reality, in that case they go on to become disillusioned like the author of the article.

>10) It’s a Race to the Bottom — and No One Gives a Shit

There's a natural tension between spending years developing a worthless Enterprise Edition of "Hello World" vs. slinging up a quick-and-dirty app in a couple of weeks that turns out to be really valuable so that you might get stuck having to extend and support it for a decade or longer. There's no clear way to consistently hit the bulls-eye in the middle, with maximal value. All the loud voices preach one end of the spectrum or the other. Experienced people have mostly tuned them out, because they're both wrong.

As much as I love and identify with these rants (keep 'em coming!), I think as much damage is done by trying to think long term (and guessing wrong) as by focusing on short term. In the abstract, I agree with the author in general that there's too much short-term thinking in software development, but in my experience, the cure is usually worse than the disease.

Another reason is the use of dynamically typed languages. In Java/C++ many categories of bugs would not compile, but for today's JS/python you need an order of magnitude more unit tests. Now you got a pike of crap that's even harder to refactor.

Surprised he didn't mention unions or professional organizations in "What is to be done?". I don't like the authors tone, but it is refreshing to see someone saying "we're not special and this sucks".