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.
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 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.
I 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.
Historically, 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.
Historically, 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.
Are 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.
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 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.
To 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.
Yep, 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.
I 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.
> 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.
Bringing 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.
The 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.
I 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:
Well, that's just the thing. Whether (we) programmers like it or not, the only relevant measure of quality in a program is whether it does the thing that the user needs it to do. In other words, "functional standards" is the only type of quality standards that you could ever expect to have for software.
Things like code quality and inner loop optimization are largely irrelevant for the people who are using the software.
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.
Bit 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.
"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.
The 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.
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.
> 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.
It 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."
We 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.
Have 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.
I 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.
This 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.
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.
No, that's not it, because usually management doesn't give a shit about that. Even if you have the paper trail, they're still going to say, "Quit whining; it's 3 AM and stuff doesn't work. Fix it."
If they want us to be responsible, then they need to give us what we need when we say we need it. You're saying they should be able to make us cut corners and then support it. You don't get to have your cake and eat it, too.
You have to win people over by making their lives easier or by making them look good. This does not necessarily have to be related to code or technology in any way.
Then, after people have a visceral positive feeling about you, make some tiny suggestion for improvement. Make the improvement, and whoever approved it, do something to make sure they associate your suggestion with a positive experience.
Slowly repeat. It is a slight selling of your soul. It is effective.
IMO there's nothing you can do to fix this culture. They're determined to ignore the inconvenient problems and then conveniently forget they were told about them. Even if you attempt to document these things, you'll just be labeled some negative name like "whistler blower" or "anal" and the same reputation problems will exist.
FWIW, 2 things mitigate this. First, some companies do actually remember people who fix things and get things done, so that's on your side. The other is that it's not likely you'll be there long-term anyhow. Companies that do this also generally fail in other departments, like paying you what you're worth as your worth increases. So you'll probably look for a new job eventually anyhow.
I know it's hard to see from where you're standing, but I wouldn't fret about it. Just keep doing your job the best you can and warning them, and let the chips fall where they may.
Perhaps you're doing what I'm about to recommend already, but I can't be sure based on what you wrote. It's in regard to "2. Team says, "Need to ship; we'll accept the risk".
If the Business Unit, for whom the software is being written, has a representative on your team, then make sure you explain the risk in purely business terms, not technical ones. A BU rep's ears are going to perk up with statements like "invalid posts may get written to the general ledger" or "1 in every 20 orders may get dropped" rather than "universally scoped variables are being overwritten by invalid data in some cases" or "uncommitted nested transactions may cause a core dump."
If your team doesn't include a BU rep, then you could always get friendly with one and explain the potential risks over coffee or lunch. Perhaps even suggest some questions the rep should ask the team before the mod goes live.
In my situation, a BU rep is always part of the team and I rarely have other developers on the team. The reps and I have lunch together regularly anyway, so they get my opinions and recommendations that way.
The only thing you're doing wrong is pointing out that you mentioned it two months ago. That's the last thing an organization faced with a problem wants to hear. What they want is for everyone to act like the problem was entirely unpredictable and have everyone make 'heroic efforts' to make the fix.
probably you're doing it too serious and taking it too personal. After 20+ years in the industry, I got desensitiveized enough to bother that much about small things, and when i point to the issue i usually do it in the "constructive" "spirit-sharing" and "team-building" way - "Ha! Just imagine how those suckers - customers or downstream devs - would be hitting that bug, completely lost at what to do, they would have no chances to make it work so we should give out a Grand Prize to the unlikely one who would make it through... " I noticed that various leaders/management/etc. have hard time to full-heartedly subscribe to that vision of future. Not that that gets the thing fixed or anything like this, mind you. Yet it helps with the blame part if/when it still comes my way - "Wow! when _we_ (me and you, the manager/etc.) were laughing at it _we_ did look into the crystal ball! _We_ are that smart!" The management somehow don't enjoy sharing in on that smartness :)
They'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.
¯\_(ツ)_/¯ 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.
The 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.
I 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.
Maybe 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.
> 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?".
Rants are purely emotional and lack any reason or evidence. Polemics are in part emotional, but also contain a significant element of reason and evidence.
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.
I 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
Yeah, 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.
> 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.
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.
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".
Unionizing 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.
> 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.
>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.
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.
> 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.
When 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.
You discover that there is rarely something new under the sun. Even the youngsters who want to show you your flaws to feel superior , they pop up like mushrooms if its the season.
> You discover that there is rarely something new under the sun.
The only people I've heard say this are those who are ignorant enough of the actual state of the art to think they've seen everything out there. If the field still has people researching it academically, you haven't seen everything under the sun.
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.
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.
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.
I 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.
I tried very hard to take the perspective that this guy is irritated but that there might be some substance to his opinion. I couldn't help but constantly think this, though, "Wow, this guy is really mad, and now wants to logically apply blame to everyone and everything except himself and his choices."
What do you propose that people that want to engage in their craft with at least a modicum of craftsmanship do?
Even if it truly weren't economical to build quality software and to use real engineering to reduce risks toward achieving that goal (realistic deadlines based on past estimation error, known unknowns in planning, evaluating and training people, scheduling refactors, avoiding defects in the planning stage, planning for the duration of components' lifetimes so you can build things and eventually replace them instead of constant myopic re-architecture) -- which I highly doubt -- who's to say we have to be motivated solely by self-interested short-term economics? If the costs are externalized, of course it's more economical to do everything as shitty as everyone can get away with. What kind of Objectivist nonsense is it to say that that's the same as correct?!
For some of us, money isn't motivating, the collective consensus isn't compelling, it's not possible to be simultaneously disengaged and productive, we find investing so much of our conscious time and effort toward something we don't value existentially frustrating and simply want our investment of time and effort to result in software of quality, as simple as trying to maximize for durable utility -- as much as possible, leaving the lives of its users better off for using it, and existing and paying that dividend for as long as possible -- (true economic value) and we find we're not allowed as the majority of managers and team mates have bought into the modern kind of myopic and psychopathic faux economics of me and now. Do you really propose that we are the ones who are wrong? If we are, what's to be done -- do we accept we aren't cut out for the rat race and go live in a van?
One of the reasons the article is so bad is that it's setting up a pile of false dichotomies, some of which you're embedding into assumptions here.
Doing stuff to serve business needs is not intrinsically bad, or opposed to craftsmanship. The whole idea of craftwork is that it serves a purpose, right? It must have an actual function, and the goal is to build a thing that serves that function well. So yes, you should absolutely build software that fulfills its purpose well. Just remember that the business is the purpose, not the software in itself.
This isn't just about economics, it's about a larger perspective. Think about the people who use your software, and every time you're thinking about what you're doing, think about how it will impact those users. Will it make their experience better, or will it just make your experience better? (If the latter, don't do it.) Will it make their experience better, but there are other things that they'd really rather have. (Ensure that you're working on the right priorities.)
A lot of the things you list as "real engineering" -- realistic deadlines, risk management -- are things that absolutely do help the users: They want to know realistically when they can expect functionality to be there so they can plan for it; they want to know what things might throw that schedule off and be kept up to date on whether they're happening. So a good workplace will use those things.
(I'd argue that some of the other items you list are actually not that beneficial, like planning for long-term evolution: The reality is that businesses evolve, and they might get a new big customer, or shift into a new line of business, that will necessitate major rewrites in the application anyway, so trying to plan for that from an engineering side is light folly. But it's mostly harmless, and sometimes helpful; and depending on your environment, maybe it would make sense.)
In particular, doing everything as shittily as possible is not beneficial to anyone. Users hate systems that flake out and don't work reliably, right? (At the same time, users might rather have a particular new feature that would save them an hour every day, rather than having you fix that one really thorny bug that's causing the system to need to be rebooted once a month. You'd rather have that, too, if you were them.)
So do stuff well, engage closely with your users and customers, think about their needs and goals, and then do the best you can to meet them, while communicating openly and honestly in a collaborative spirit, and committing as a team to high standards.
It really does work, in a way that a dedication to cynicism never will.
Maybe you're just not imagining the kinds of workplaces that we work in where we have these problems?
There are teams where the political consensus is that even considering security risks is useless - who aren't budged on that position when after violating PCI DSS and having a database full of plaintext payment card information and also having a shitty copy-pasted-from-the-internet PHP newsletter form with an SQLi have payment card info stolen and used in fraud. "They probably won't sue" so even just fixing the SQLi wasn't important to them.
There are teams where "SVN and Git are hard, so we just use Dreamweaver on the shared drive and use the built in file locking to make sure nobody steps on eachother's toes".
There are teams where plaintext FTP deployment to production sites on plaintext WIFI is standard operating procedure. I couldn't convince them to change it even after showing them the username and password in Wireshark. "Anyone in the neighborhood could steal all of our client's data." wasn't scary.
There are teams where leadership has no idea of technical realities, forms bad plans in the style of "We want to make Twitter, but for IoT thermostats" and gets to set the budget for those plans before even talking to a project manager or developer, and every initiative fails (doubly since they go over their nonsense budget, and have no nonsense customers buy into it) but it's fine because it's not like anyone will ever lose their job because they're 5 levels down from the CEO and five levels up from individual contributors in the software part of a hardware-focused fortune 500 so nobody in the C-suite understands or cares what they do and it's not consequential to the level where it shows up in shareholders reports.
There are teams where they use a CMS + custom fields features and pretend it's an MVC framework and build line of business apps with only a few models but internal storage abstraction of the CMS and custom field feature blows that up into hundreds of tables with mutiple-tens-of-ways joins, and normal usage starts to DoS it and nobody can accept that they get to re-architect or even at least fucking throttle requests, it's just "fix it", who knows how.
Bad workplaces definitely exist. Sometimes, they can be changed, and there's a ton of scope for you to be the person who came in and got a dysfunctional department functional; sometimes, they're broken at a higher level than you can fix, and you just need to leave.
But if you work at a bad workplace and your takeaway is "this industry is completely broken" and you turn into a full-bore cynic who refuses to believe that anything better is possible, you've gone badly astray.
I've left. I've left every time, and I've got a resume full of shit jobs I left after a year because they were shit, and I'm not sure what to do at this point to get the kind of position where this isn't how things are, where the sky is blue and up isn't down.
If there's part of the industry that's not like this, I haven't seen it and none of the people I've worked with have seen it, and I don't know it. At this point my wife has all but begged me to give up and settle for steady money with no purpose, my therapist is telling me to consider going back to school and pull a career change. I'm the only person I know in real life where there's any expectation that software makes sense and I question myself, wondering if pragmatic engineering in software is just a fantasy perpetuated by strangers on the internet.
Nah man. I've had the same experience until my current job and I think the only reason my teams been given the power to so things right is because the company went through 2-3 other teams that would take 6 months to take data from one of our services and put it in an excel sheet. Most of the places I have worked have had the engineers so far removed from anyone who had the power to actually allow changes to the process, that me and my coworkers didn't even know what they looked like. It seems like a matter of luck of being in the right place and right time, so that managers have had so many failures in software development that they are finally open to listening to alternatives
Search for companies whose products you respect, and have quality design, and apply to them. Also, look for areas that require good quality - safety critical, high reliability systems for example.
It's not guaranteed, nothing is, but there are good working environments out there.
I'm in the same position. Plus with too many short term positions on your resume it makes finding a job at all (let alone a decent one) harder.
I have been at one place that was good though, unfortunately I left it to relocate. I haven't found anyway remotely close to the same quality in they ~6 years since.
I've developed a few proxy questions to estimate exactly how shit they are though.
Definitely have a refined set of interview questions developed, if nothing else to show for it. Never really get past:
"Walk me through the steps of the your design process, what steps does software go through to get from conception to production on your team, who is responsible for each step, and how do they test the assumptions inherent in their designs?"
"Uh... well... <handwaving about how roles aren't defined so nobody's responsible, why wouldn't you be confident about your 'decisions', maybe 'design' is too strong a word?>"
My best is "when I fix a bug, what are the steps to get it in production". It gives an insight into the corporate culture as well as their automation level.
Also, anywhere that uses TFS is an instant no, and I think SVN will be on that list now too.
Agree. Truly bad software is going to be bad for the business. Software that grows more complex is rendered that much less adaptable to changing requirements, requiring more resources for its adaption. I accept that some employers and managers do not understand that reality, that maintenance can benefit adaptability and upfront work can create a better starting point that ultimately benefits the business as a whole by enabling more efficient execution.
However, there is also the danger of having an engineer who is mired in trying to achieve some (often incoherent or misguided) state of perfection, guided by a religious commitment to an unspecified measure of "best", paralyzed by the sheer number of ways something could be improved in some conceivable way. He risks living in a bubble, disconnected from the larger goal and reality the software he is working on is a part of. This disconnect results in bad prioritization and little grasp of trade-offs. The idea of "long-term planning" is also problematic because, taken too far, can become an exercise in speculation and fortune-telling. As Woody Allen said, if you want to make God laugh, tell him your plans. You can aim in a general direction, but expect course correction. There is no "once-and-for-all".
Effective engineering requires prudence. Mature and seasoned engineers are better able to distinguish actual needs from possible needs or wants, make decisions and prioritize work based on the limited resources they have. There are programming techniques and approaches (if not wholesale methodologies) that are motivated by this wisdom and that enable an engineer to manage the evolution of his software.
Between the extremes, there is a range of reasonable opinion and approaches. To me, it sounds like the author is either working in an exceptionally bad company or suffers from OCD.
> 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.
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.
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?"
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.
I 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.
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.
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 devel...
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.
120 comments
[ 4.7 ms ] story [ 158 ms ] threadIt 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.
Spot on. Not to mention all the future debugging time you saved by deleting code.
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.
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.
At some point (agile?) we explicitly gave up all moral responsibility for our creations, to people with money.
In that case, the mechanical engineer would certainly acquiesce, just like most of us do when management prefers speed/cost to scalability.
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.
- 508 / ADA compliance
- HIPAA
- AICC / SCORM / cmi5
- PCI / DSS
Things like code quality and inner loop optimization are largely irrelevant for the people who are using the software.
You hit the nail on the head. It happened when we stopped financing our own work.
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.
"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.
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.
Maybe they should. There's a reason agile won; it was and remains more efficient than the alternatives.
Better from the market's POV != better for the people who use it.
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.
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.
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.
That's insulting for the cows !
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...
In the country of the blind, the one eyed man gets locked up in a lunatic asylum.
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.
Then, after people have a visceral positive feeling about you, make some tiny suggestion for improvement. Make the improvement, and whoever approved it, do something to make sure they associate your suggestion with a positive experience.
Slowly repeat. It is a slight selling of your soul. It is effective.
FWIW, 2 things mitigate this. First, some companies do actually remember people who fix things and get things done, so that's on your side. The other is that it's not likely you'll be there long-term anyhow. Companies that do this also generally fail in other departments, like paying you what you're worth as your worth increases. So you'll probably look for a new job eventually anyhow.
I know it's hard to see from where you're standing, but I wouldn't fret about it. Just keep doing your job the best you can and warning them, and let the chips fall where they may.
If the Business Unit, for whom the software is being written, has a representative on your team, then make sure you explain the risk in purely business terms, not technical ones. A BU rep's ears are going to perk up with statements like "invalid posts may get written to the general ledger" or "1 in every 20 orders may get dropped" rather than "universally scoped variables are being overwritten by invalid data in some cases" or "uncommitted nested transactions may cause a core dump."
If your team doesn't include a BU rep, then you could always get friendly with one and explain the potential risks over coffee or lunch. Perhaps even suggest some questions the rep should ask the team before the mod goes live.
In my situation, a BU rep is always part of the team and I rarely have other developers on the team. The reps and I have lunch together regularly anyway, so they get my opinions and recommendations that way.
>Not sure what I'm doing wrong...
probably you're doing it too serious and taking it too personal. After 20+ years in the industry, I got desensitiveized enough to bother that much about small things, and when i point to the issue i usually do it in the "constructive" "spirit-sharing" and "team-building" way - "Ha! Just imagine how those suckers - customers or downstream devs - would be hitting that bug, completely lost at what to do, they would have no chances to make it work so we should give out a Grand Prize to the unlikely one who would make it through... " I noticed that various leaders/management/etc. have hard time to full-heartedly subscribe to that vision of future. Not that that gets the thing fixed or anything like this, mind you. Yet it helps with the blame part if/when it still comes my way - "Wow! when _we_ (me and you, the manager/etc.) were laughing at it _we_ did look into the crystal ball! _We_ are that smart!" The management somehow don't enjoy sharing in on that smartness :)
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.
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.
Do you get that?
Things shouldn't be this way, that's the whole point of the article.
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.
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?".
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.
Likewise, it's silly to make categorical statements to not take the blame for anything all the time.
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.
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.
Yeah, it was rude. But it does some up the end of some weeks.
And I think you mean "sum up" ;)
>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.
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.
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.
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.
This is an interesting claim. What do you mean by this?
The only people I've heard say this are those who are ignorant enough of the actual state of the art to think they've seen everything out there. If the field still has people researching it academically, you haven't seen everything under the sun.
Instead we get yet another generic build tool or MVC framework. React actually reminds me of writing php/asp code more than a decade ago.
When you're just starting out, learning $foo when all you ever knew was $bar is radical change that upends the world.
To the more experienced, learning about the existence of $foo is just another $whatsit with $properties and maybe $novel_feature.
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.
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.
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.
Well commented, thanks.
Even if it truly weren't economical to build quality software and to use real engineering to reduce risks toward achieving that goal (realistic deadlines based on past estimation error, known unknowns in planning, evaluating and training people, scheduling refactors, avoiding defects in the planning stage, planning for the duration of components' lifetimes so you can build things and eventually replace them instead of constant myopic re-architecture) -- which I highly doubt -- who's to say we have to be motivated solely by self-interested short-term economics? If the costs are externalized, of course it's more economical to do everything as shitty as everyone can get away with. What kind of Objectivist nonsense is it to say that that's the same as correct?!
For some of us, money isn't motivating, the collective consensus isn't compelling, it's not possible to be simultaneously disengaged and productive, we find investing so much of our conscious time and effort toward something we don't value existentially frustrating and simply want our investment of time and effort to result in software of quality, as simple as trying to maximize for durable utility -- as much as possible, leaving the lives of its users better off for using it, and existing and paying that dividend for as long as possible -- (true economic value) and we find we're not allowed as the majority of managers and team mates have bought into the modern kind of myopic and psychopathic faux economics of me and now. Do you really propose that we are the ones who are wrong? If we are, what's to be done -- do we accept we aren't cut out for the rat race and go live in a van?
Doing stuff to serve business needs is not intrinsically bad, or opposed to craftsmanship. The whole idea of craftwork is that it serves a purpose, right? It must have an actual function, and the goal is to build a thing that serves that function well. So yes, you should absolutely build software that fulfills its purpose well. Just remember that the business is the purpose, not the software in itself.
This isn't just about economics, it's about a larger perspective. Think about the people who use your software, and every time you're thinking about what you're doing, think about how it will impact those users. Will it make their experience better, or will it just make your experience better? (If the latter, don't do it.) Will it make their experience better, but there are other things that they'd really rather have. (Ensure that you're working on the right priorities.)
A lot of the things you list as "real engineering" -- realistic deadlines, risk management -- are things that absolutely do help the users: They want to know realistically when they can expect functionality to be there so they can plan for it; they want to know what things might throw that schedule off and be kept up to date on whether they're happening. So a good workplace will use those things.
(I'd argue that some of the other items you list are actually not that beneficial, like planning for long-term evolution: The reality is that businesses evolve, and they might get a new big customer, or shift into a new line of business, that will necessitate major rewrites in the application anyway, so trying to plan for that from an engineering side is light folly. But it's mostly harmless, and sometimes helpful; and depending on your environment, maybe it would make sense.)
In particular, doing everything as shittily as possible is not beneficial to anyone. Users hate systems that flake out and don't work reliably, right? (At the same time, users might rather have a particular new feature that would save them an hour every day, rather than having you fix that one really thorny bug that's causing the system to need to be rebooted once a month. You'd rather have that, too, if you were them.)
So do stuff well, engage closely with your users and customers, think about their needs and goals, and then do the best you can to meet them, while communicating openly and honestly in a collaborative spirit, and committing as a team to high standards.
It really does work, in a way that a dedication to cynicism never will.
There are teams where the political consensus is that even considering security risks is useless - who aren't budged on that position when after violating PCI DSS and having a database full of plaintext payment card information and also having a shitty copy-pasted-from-the-internet PHP newsletter form with an SQLi have payment card info stolen and used in fraud. "They probably won't sue" so even just fixing the SQLi wasn't important to them.
There are teams where "SVN and Git are hard, so we just use Dreamweaver on the shared drive and use the built in file locking to make sure nobody steps on eachother's toes".
There are teams where plaintext FTP deployment to production sites on plaintext WIFI is standard operating procedure. I couldn't convince them to change it even after showing them the username and password in Wireshark. "Anyone in the neighborhood could steal all of our client's data." wasn't scary.
There are teams where leadership has no idea of technical realities, forms bad plans in the style of "We want to make Twitter, but for IoT thermostats" and gets to set the budget for those plans before even talking to a project manager or developer, and every initiative fails (doubly since they go over their nonsense budget, and have no nonsense customers buy into it) but it's fine because it's not like anyone will ever lose their job because they're 5 levels down from the CEO and five levels up from individual contributors in the software part of a hardware-focused fortune 500 so nobody in the C-suite understands or cares what they do and it's not consequential to the level where it shows up in shareholders reports.
There are teams where they use a CMS + custom fields features and pretend it's an MVC framework and build line of business apps with only a few models but internal storage abstraction of the CMS and custom field feature blows that up into hundreds of tables with mutiple-tens-of-ways joins, and normal usage starts to DoS it and nobody can accept that they get to re-architect or even at least fucking throttle requests, it's just "fix it", who knows how.
But if you work at a bad workplace and your takeaway is "this industry is completely broken" and you turn into a full-bore cynic who refuses to believe that anything better is possible, you've gone badly astray.
If there's part of the industry that's not like this, I haven't seen it and none of the people I've worked with have seen it, and I don't know it. At this point my wife has all but begged me to give up and settle for steady money with no purpose, my therapist is telling me to consider going back to school and pull a career change. I'm the only person I know in real life where there's any expectation that software makes sense and I question myself, wondering if pragmatic engineering in software is just a fantasy perpetuated by strangers on the internet.
It's not guaranteed, nothing is, but there are good working environments out there.
I have been at one place that was good though, unfortunately I left it to relocate. I haven't found anyway remotely close to the same quality in they ~6 years since.
I've developed a few proxy questions to estimate exactly how shit they are though.
"Walk me through the steps of the your design process, what steps does software go through to get from conception to production on your team, who is responsible for each step, and how do they test the assumptions inherent in their designs?"
"Uh... well... <handwaving about how roles aren't defined so nobody's responsible, why wouldn't you be confident about your 'decisions', maybe 'design' is too strong a word?>"
Also, anywhere that uses TFS is an instant no, and I think SVN will be on that list now too.
However, there is also the danger of having an engineer who is mired in trying to achieve some (often incoherent or misguided) state of perfection, guided by a religious commitment to an unspecified measure of "best", paralyzed by the sheer number of ways something could be improved in some conceivable way. He risks living in a bubble, disconnected from the larger goal and reality the software he is working on is a part of. This disconnect results in bad prioritization and little grasp of trade-offs. The idea of "long-term planning" is also problematic because, taken too far, can become an exercise in speculation and fortune-telling. As Woody Allen said, if you want to make God laugh, tell him your plans. You can aim in a general direction, but expect course correction. There is no "once-and-for-all".
Effective engineering requires prudence. Mature and seasoned engineers are better able to distinguish actual needs from possible needs or wants, make decisions and prioritize work based on the limited resources they have. There are programming techniques and approaches (if not wholesale methodologies) that are motivated by this wisdom and that enable an engineer to manage the evolution of his software.
Between the extremes, there is a range of reasonable opinion and approaches. To me, it sounds like the author is either working in an exceptionally bad company or suffers from OCD.
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.
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.
Need to flesh them out..
https://github.com/eugenejen/enterprisey_mantras
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?"
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.
Great quote. I've seen some great code quickly turn to spaghetti under the guise of Collective Code Ownership.
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.
>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 devel...
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.