10 ms·
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 lo
by mi100hael 10y ago
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.
- 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.
- flukus 10y agoI can understand that, but they seem oblivious to the long term cost too. They usually have no idea how seriously technical debt will affect them 3 years down the road and by the time it gets to the point they can't even hire anyone decent willing to work with the code.
- cornchips 10y agoAgree. We would have dramatically less surveillance programs, automated enforcement and bombs if there wasn't as many people ready to blindly write the software for them. We should be thinking hard about what we are building and how it will be [ab]used, especially in government.
- mi100hael 10y agoBit of a jump there, no? The ethics of building crap commercial software is quite a bit different than the ethics of building mass surveillance or munitions software.
- cornchips 10y agoNo. "I try to stay much less emotionally attached to the end-result". This is the mindset that drives most of military, police and totalitarian policy. You don't drop a bomb or violate the constitution without a bit of emotional divestment.
- mi100hael 10y agoThe mindset may be the same. The ethics behind adopting that mindset are very different. No one dies if Tinder crashes because it tried to load too many images at once.
- neffy 10y ago> Does a bridge Engineer find it acceptable to give notice "The bridge will fall in high winds". Not any more. But in the 19th century bridge failure was quite frequent, until things like the Tay Bridge Disaster happened, and then some standards were imposed, and engineers and others were empowered to enforce high standards. In any field you can have fast development, or you can have safe development, but you really can´t have both. It remains to be seen quite what level of software disaster it will take to bring this lesson home in our industry.
- crpatino 10y agoIf last Friday events do not, I am not sure what will.
- quantumhobbit 10y agoBringing down Twitter for part of the country for a few hours likely won't be enough. Unfortunately it will probably take people being physically hurt or shutting off most of the internet for days at a time.
- mojuba 10y agoThe tragedy is that, with non-critical software that can't kill anyone, users are happy with most bugs most of the time. Therefore we will never have legal quality standards for most types of software.
- ghurtado 10y agoI realize that you're talking about "quality standards", but depending on the industry, there are plenty of legally mandated software standards out there. You're likely to run into some of them if you haven't already: - 508 / ADA compliance - HIPAA - AICC / SCORM / cmi5 - PCI / DSS
- 0xdeadbeefbabe 10y agoSome of those are not very good i.e. not quality standards. Is there a quality standard for quality standards or does the buck stop there?
- jefurii 10y ago> At some point (agile?) we explicitly gave up all moral responsibility for our creations, to people with money. You hit the nail on the head. It happened when we stopped financing our own work.
- nkrisc 10y agoI believe there clearly is a difference when lives are at stake. Often that is not the case with software (but it can be!).
- crpatino 10y agoYou don't know that, and cannot know that. Our industry loves to write CYA statements about the product not being intended to be used in critical situations and bury it in the fineprint of licenses we know customers do not ready anyways. Then, we act surprised when the same customers go and use the product in life or death situatioins. This is not theoretical, just to highlight the most well known example: Our current generation of social media was created for the purpose of allowing college aged people in first world nations to share trivial details about their personal lives with friends and aquaintances. But now we see activists using the same media to organize civil resistance against governments; specially governments with huge stains in their human rights record.
- lmm 10y ago> 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? Maybe they should. There's a reason agile won; it was and remains more efficient than the alternatives.
- TeMPOraL 10y agoMore efficient in producing crap solutions that can be sold by reinvesting time and money into sales and marketing, yes. Better from the market's POV != better for the people who use it.
- flukus 10y agoWhich is still an improvement on taking months/years to produce a crap solution that also doesn't do what the client wants, as was the case before.
- kps 10y agoUpper-case ‘Agile’ won because it's micromanagement without the blame falling on the managers.
- clifanatic 10y ago"If builders built buildings the way programmers write programs, the first woodpecker that came along would destroy civilization".
- pjlegato 10y agoIt wasn't that we gave up responsibility; it was that we were told "ignore those problems and build it poorly anyway, because if you don't we'll just replace you with someone who will."
- st3v3r 10y agoWe abdicated responsibility when management decided to stop giving us the time we said it was actually going to take. I don't know about you, but if I'm not given what I need to do something, there is no way in hell I'm going to take responsibility for it. EDIT: Not to mention that, if I do hold my ground and refuse to do something until I have what I need, the company is going to fire me and find someone who doesn't give a shit. And quite frankly, I like being able to buy food.
- omouse 10y agoHave you ever had a project manager who has software development skills and experience? It seems like there is a class division now, even at startups where the devs are on the frontlines and all actual decisions are kicked up a hierarchy. If there's a quality issue, the frontline devs should be able to blow the whistle and get the problems resolved because we have the technical knowledge to identify the problem and to fix it. CYA, Cover Your Ass, is a good call though since the tech companies aim to keep developers down.
- HeyLaughingBoy 10y agoI have never had a project manager who did not have software development skills and experience. It really doesn't make a difference: they still need to trust the team they're leading. Developers need an appropriate level of authority. Building something safety-critical? Every dev needs to be able to "pull the rope and stop the train" if something isn't right. Building a toy? Kick the "this is fragile, should we do it?" questions up to the PM. I don't want my devs deciding to arbitrarily gold-plate every trivial feature, but at the same time, if there's a latent quality problem, I need to know about it.
- TeMPOraL 10y agoThis sucks. Like 'hawleyal wrote, survival requires it - but it's painful, because you can't get attached to the product you're working on. If you do, you'll be fighting with the management, customers and/or cow-orkers.
- throwaway1892 10y ago>... cow-orkers ... That's insulting for the cows !
- crpatino 10y agoFunny... but surely you should be thinking of the orks as well.
- sidlls 10y agoI've been employed at places where that email trail is ignored or used as "evidence" against the engineer.
- snockerton 10y agoThis is the same CYA attitude that I have been assuming the last 2 years because it's such a frequent occurrence. The only issue is that I still get blamed. I don't know how many times I've repeated this scenario: 1. I highlight gap / issue in code. 2. Team says, "Need to ship; we'll accept the risk" 3. During go-live, fecal matter hits fan because of aforementioned gap in code. 4. Everyone acts surprised. 5. I point out that I mentioned it 2 months ago. 6. Everyone makes excuses / claims they don't remember it that way / moves on to burn down another project. 7. I'm left to clean up a mess / have taken a hit to my reputation. Not sure what I'm doing wrong...
- ScottBurson 10y agoNext time you raise an issue, point out what happened last time. Then fix it.
- neffy 10y agoNothing... In the country of the blind, the one eyed man gets locked up in a lunatic asylum.
- rhapsodic 10y ago> Not sure what I'm doing wrong... Perhaps you failed to build a paper trail (i.e. an email trail) to document the fact that you predicted the disaster, and who it was that decided to ignore your warnings. If you do that, when the fingers start pointing in your direction, you can send everyone copies of the emails that prove who is responsible for the mess.
- pjlegato 10y agoThey're not interested in your email trail. They just want a scapegoat. You're not put on trial first before you're fired; you're just summarily shown the door. Since you're not given any chance to defend yourself, your documentation doesn't matter. Blaming an engineer for supposedly poor engineering is a lot more politically viable than blaming management for poor management -- because they're higher on the chain of command than you are.
- mi100hael 10y ago¯\_(ツ)_/¯ It's worked for me thus far. Actually, most of the time the situations have improved. If you go about raising your concerns tactfully, people start taking your opinions more seriously because you accurately forecasted problems in the past. It can also work to just take a little longer on a feature and do some cleanup/fixing without getting permission. If anyone bothers you about it, just say "I noticed this issue and wanted to avoid running into problem xyz again since it took us offline last week." Again, most of this boils down to tact. Project managers don't like looking bad to upper management. Usually you just have to point out (tactfully!) how dumb they will look if something crashes in prod on a weekend.
- st3v3r 10y agoThe problem is, those problems with the code end up becoming the fires that you then have to fix on your off time. You think you have your ass covered, but management isn't going to give a shit that you have this paper trail. They're going to see that shit isn't working, and you're going slow and bringing up ancient history.
- pfarnsworth 10y agoI did this at a previous company, and got blackballed for having a "negative attitude". 6 months after I told my manager and the technical architects that it wouldn't scale, the project got cancelled because it didn't scale. No one suffered except for me because I had the balls to open my mouth.
- carapace 10y agoNot to pick on you especially but, uh, you are evidently one of the toxic co-workers the guy was ranting about: you are enabling the fuckery. Do you get that? Things shouldn't be this way, that's the whole point of the article.
- mi100hael 10y agoMaybe to some extent I am. But I have enough senior/architect experience to have dealt with all of the issues the author raises. Inheriting tech debt, bad developers writing code that needs to be immediately re-written, lazy developers that just don't give a fuck, etc. With a perfect team of developers and a perfect management team, there would be no problems. Unfortunately, we all have to deal with idiot developers or idiot managers or idiot customers at least occasionally. I don't intentionally enable fuckery, but I've learned long-term career happiness depends on picking your battles wisely.
- carapace 10y agoWow, you're good. ;-) I apologize. I'm frustrated at work, I don't understand why all these intelligent, capable people wind up building such a haphazard, nearly spastic organization. I should not fault you for coping, even thriving, in a world not of your own making.