12 ms·
Anti-patterns and Malpractices in Modern Software Development (2015)
- SFJulie 10y agoThe 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.
- quantumhobbit 10y agoThe 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?
- eeZah7Ux 10y ago> Guess what looks better to management though? Spot on. Not to mention all the future debugging time you saved by deleting code.
- wccrawford 10y agoI had a job like this. Nobody wanted to do bug fixes except me. I was happy taking on that responsibility, and I was good at it, so I volunteered. I took on fewer Scrum tickets than others because I was partially allocated to bugfixes. I think it's coincidence, but that was around the same year I stopped getting good raises there. I quit after a couple years of that and went to get get paid what I'm worth. I still think it's because the new IT boss didn't like me. I was the only one that would stand up and say when a new policy was stupid. Still, I can no longer rule out the bug-fix thing, after reading your comment.
- clintonb 10y agoI see your point. What does your test suite look like? Are tests run before pull requests are merged? Automated testing, and gating merges on tests passing, would push the responsibility back to those breaking functionality.
- dasmoth 10y agoHistorically, plenty of projects have worked fine without 100% test coverage and lots of CI infrastructure. If you're saying that collective code ownership requires these things just to work at all, that sounds like a fairly powerful argument against collective code ownership.
- flukus 10y agoHistorically, plenty of projects had bugs in them for years without anyone noticing. I've come across situations were I've been modifying and rewriting stuff and found that clients have been under billed for a decade costing many millions of dollars.
- dasmoth 10y agoAre you positive that the clients would have remained clients if they'd been billed "correctly"? I have trouble getting excited about "X has been broken for years" except in pretty special cases, e.g. code paths that only get exercised when your Mars lander is about to touch down.
- mi100hael 10y agoI 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.
- hawleyal 10y agoAgreed. Survival requires it. Still feels like a shame to knowingly spend a lot of your time making garbage for money. MLIA
- JoeAltmaier 10y agoI know this is how it works. But it troubles me. When did we abdicate responsibility for the systems we built? Does a bridge Engineer find it acceptable to give notice "The bridge will fall in high winds". Then build the bridge anyway when management decides its an acceptable risk? At some point (agile?) we explicitly gave up all moral responsibility for our creations, to people with money.
- rfrey 10y agoTo be fair, for the vast majority of software projects it's more like "The plastic canopy on this toy firetruck will crack if a child steps on it, which they will", and management saying "nope, use that cheaper plastic anyhow". In that case, the mechanical engineer would certainly acquiesce, just like most of us do when management prefers speed/cost to scalability.
- mi100hael 10y agoYep, exactly. I think most of the time management isn't totally blind to the risks of crap software, it's just a matter of weighing the time & cost vs risk and deciding what the acceptable ratio is. Obviously I want to put out the absolute cleanest, best possible application, but one that gets the job done without crashing is all the business can justify time & cost-wise.
- blowski 10y ago> 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?".
- frozenport 10y agoAnother 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.
- arenaninja 10y agoI agree. The speed of development in PHP can be great, but good luck convincing developers who haven't used anything else that using the type system would cut down a number of common bugs, or that the responsibility of this or that should be elsewhere
- ljw1001 10y agoYeah, it's the curse of Java that it takes longer to get something working, but it more than makes up the time in maintenance. No one can think far enough ahead to care about maintenance.
- platz 10y ago> 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.
- usgroup 10y agoEerily 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.
- wcummings 10y agoSurprised 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".
- wyager 10y agoUnionizing is just a different approach to becoming a soulless, legalistic profession. It would make most of the stuff the article is complaining about worse, not better.
- JumpCrisscross 10y ago> 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.
- Roboprog 10y agoAww. Somebody changed the title on the link. :-( Yeah, it was rude. But it does some up the end of some weeks.
- clifanatic 10y agoWhat was it originally? And I think you mean "sum up" ;)
- omouse 10y agothis 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.
- jondubois 10y agoSoftware 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.
- ghurtado 10y ago> I really do think that software engineering damages you emotionally and mentally. The best software engineers that I know also the most cynical people I know - All atheists, nihilists and pessimists. Although I don't disagree with your statement regarding emotional consequences, I would argue that these personality traits are just as likely to be a predictor of someone that ends up becoming a software developer, rather than a side effect of doing the job for a number of years. I can definitely speak for myself having been an atheist, nihilist and pessimist for quite a bit longer than I have been a software developer.
- jondubois 10y agoWhen I started, I was agnostic and an optimist; now I'm a pessimist athiest. Psychologically speaking, debugging forces you confront and correct flaws in your reasoning. If you do it 10 to 100 times a day for 10 years or more, I think that your reasoning skills become a lot sharper. I think you have a point though. Maybe it's more of a feedback cycle. Anyway, it's just a random thought.
- wyager 10y ago> you know pretty much everything that there is to know about software. This is an interesting claim. What do you mean by this?
- tempodox 10y agoFinally 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.
- clifanatic 10y agoAs 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.
- mkozlows 10y agoI 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.
- deleted 10y ago[deleted]
- vosper 10y agoI couldn't upvote this enough. Also, come on, it's not like everyone doesn't have bullshit in their workplace. I've never heard anyone except software engineers be so self-righteous and pretentious about our supposed special value in the business. Disdain and lack of empathy for working with other human beings comes a close second. Edit, to add: This is by no means universal. I know and have enjoyed working with some very talented, humble, and empathetic engineers, too. I don't think most programmers have the attitude of the author of the article.
- 0xdeadbeefbabe 10y ago> 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.
- vesak 10y agoThe 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.
- flukus 10y agoIME, most environments are this toxic. At least the ones hiring are.
- eugenejen 10y agoSeveral 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 https://github.com/eugenejen/enterprisey_mantras
- BjoernKW 10y agoThe "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?"
- carapace 10y agoI 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.
- pards 10y ago>> "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.
- Etheryte 10y agoHas there ever been an era in software development when most people are happy with the current practices?
- dasmoth 10y agoI think that the microcomputer market of the 1980s perhaps came close in places. The modern industry -- with its emphasis on teams and process -- seems like a reaction to that era.
- cerrelio 10y agoI 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.
- Falkon1313 10y agoThis 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.
- NumberSix 10y agoThe 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.