
Anti-patterns and Malpractices in Modern Software Development (2015) - mirceasoaica
https://medium.com/@bryanedds/living-in-the-age-of-software-fuckery-8859f81ca877#.aq7d22evm
======
mi100hael
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.

~~~
JoeAltmaier
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.

~~~
neffy
> 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.

~~~
mojuba
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.

~~~
ghurtado
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:

\- 508 / ADA compliance

\- HIPAA

\- AICC / SCORM / cmi5

\- PCI / DSS

~~~
0xdeadbeefbabe
Some 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?

~~~
ghurtado
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.

------
mkozlows
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.

~~~
lotyrin
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?

~~~
mkozlows
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.

~~~
lotyrin
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.

~~~
mkozlows
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.

~~~
lotyrin
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.

~~~
flukus
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.

~~~
lotyrin
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?>"

~~~
flukus
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.

------
jondubois
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.

~~~
ghurtado
> I really do think that software engineering damages you emotionally and
> mentally. The best software engineers that I know also the most cynical
> people I know - All atheists, nihilists and pessimists.

Although I don't disagree with your statement regarding emotional
consequences, I would argue that these personality traits are just as likely
to be a predictor of someone that ends up becoming a software developer,
rather than a side effect of doing the job for a number of years.

I can definitely speak for myself having been an atheist, nihilist and
pessimist for quite a bit longer than I have been a software developer.

~~~
jondubois
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.

------
quantumhobbit
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?

~~~
clintonb
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.

~~~
dasmoth
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.

~~~
flukus
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.

~~~
dasmoth
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.

------
carapace
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.

------
BjoernKW
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?"

------
blowski
> 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?".

~~~
metaphorm
it was a polemic, but that is not the same thing as a rant.

~~~
blowski
What's the difference? I understand both to mean 'an angry, emotional attack
on something'.

~~~
TeMPOraL
A polemic is a rant that they teach about in literature classes.

------
vesak
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.

~~~
flukus
IME, most environments are this toxic. At least the ones hiring are.

------
omouse
this is my favourite part:

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

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

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

------
SFJulie
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.

------
cerrelio
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.

------
NumberSix
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.

------
tempodox
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.

------
platz
> 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.

~~~
wyager
Sometimes, things actually are other people's fault. It's silly to take the
blame for everything all the time.

~~~
platz
OP is not using such conditionals/qualifiers in his logic.

Likewise, it's silly to make categorical statements to not take the blame for
anything all the time.

------
usgroup
Eerily accurate stuff ...

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

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

------
0xdeadbeefbabe
> 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.

------
JumpCrisscross
> _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.

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

Need to flesh them out..

[https://github.com/eugenejen/enterprisey_mantras](https://github.com/eugenejen/enterprisey_mantras)

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

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

~~~
clifanatic
What was it originally?

And I think you mean "sum up" ;)

~~~
Roboprog
Living in the Age of Software <<expletive as adjective-ish noun>>

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

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

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

~~~
dasmoth
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.

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

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

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

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

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

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

>3) The Software Architect is a Politician

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

>4) Suffering is the Commodity That you Provide

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

>5) Your Peers Won't Support Change

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

>6) Someone is Always Ready to Undercut You

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

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

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

>8) Methodologies Are Management Tools

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

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

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

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

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

------
clifanatic
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.

------
frozenport
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.

~~~
arenaninja
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

------
wcummings
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".

~~~
wyager
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.

