
What Happened to Software Development? - gballan
https://hackernoon.com/what-happened-to-software-development-j92032w9
======
nmyk
> I decided to pack up and go, and left the USA on 11/15/2010, intending to
> retire at 56, play my guitars, read my physics library, live my life in very
> strange language and relax.

This is someone who prefers solitude. It's not surprising that he doesn't like
collaborative work.

He seems to be projecting his own preference onto the software industry
though, which is misguided. Lots of great software has been built with all
kinds of different workflows.

~~~
zozbot234
>> ... play my guitars ...

Nah, he's just a _literal_ rockstar programmer. You've got to give him that.

~~~
hootbootscoot
way to cheer for babylon, my future grumpy old fart in waiting...

------
marcus_holmes
I've worked in both environments (I too was coding in the 90's).

It was definitely easier in the 90's - less complexity, more freedom to do
your own stuff. Project management was less hands-on, and more concerned with
reporting up than managing down.

But I like it now. I like that the teamwork matters, and the morning standups
are great (good to know what your colleagues are working on, and be able to
work out if you need to collaborate with them on stuff you're both touching).
I like pair programming on the tricky bits (and being able to admit that some
bits are tricky and ask for help without being sneered at).

Programmers used to be treated as weird, eccentric geniuses that you had to
handle with care and needed special work environments to thrive in. Now we're
just people, and get treated like normal people. I understand how that won't
suit some, because they enjoyed being treated differently ("like princes" I
guess... but more like princesses because we were effectively locked in a
tower).

And as we get older, our tolerance for change decreases. It takes effort to
avoid becoming a grumpy old fart, complaining at everything that has changed.
But the effort is worth it.

~~~
hootbootscoot
.... and there you go proving the authors point about derision and subtle
sneers aimed at what is arguably the most effective means of getting focused
highly productive developers: treating them like HUMANS, instead of faceless
cogs, and allowing for focused programming time without distractions.

"old farts" rock, my friend. I get that some folks enjoy molding young minds
to sick patterns, free of pushback, but ultimately I will contend that it's
it's counterproductive to ones true goals. (unless ones true goals are merely
to crush human egos and souls...)

~~~
marcus_holmes
I said nothing about treating people like humans, or not, and nothing about
focus (I completely agree that developers should work in their own offices,
and love working from home myself). I said we used to be treated like socially
inept geniuses, left to our devices because no-one understood what the hell we
were talking about. And now we're treated like everyone else. If that doesn't
mean "like a human" then you're working for the wrong organisation, my friend.

I'm an old fart. I have to spend effort resisting the pull to be a grumpy old
fart, though. It's not like it used to be, and mostly that's a _good_ thing.

------
kilburn
What's up with the pair programming hate? I think it is great in the correct
situations and would love to do more of it!

1\. Get paired with another dev of similar level to work on new stuff.
Bouncing ideas makes the surfacing solutions better.

2\. Get paired with a dev that has been working on some system for a while.
This is a much quicker way to learn the what's and why's of a project.

~~~
thrower123
Because it is awful for people who don't enjoy social interaction, and get
quickly worn out by it. Which encompasses a much larger share of programmers
than the general public.

Everything in modern faddish programming seems to be aimed squarely at
stressing out and destroying the effectiveness of introverts.

~~~
cameronfraser
Pair programming isn't intended to be an all the time thing. A great example
of pair programming is a new person gets hired and you pair program with them
on a ticket so they can ask questions along the way. Having recently joined a
remote startup I found this to be pretty essential to getting anything done.
It's a great way of elevating programming level as well. You see different
ways of doing things, different tools they use, etc.

Introverts are also not being targeted in any way. People who have been at
this a while are just very aware that you can get far more accomplished with a
team that works well together than an individual developer can. You can be an
introvert and still an effective team member. Nobody is fully introverted or
fully extroverted.

------
Nerdfest
In my (probably worthless) opinion, the two big problems affecting software
industry are:

\- Organizations, especially large ones, now trust their process over their
people. In the "old" days, when a production problem was identified and the
prime developer knew what the problem was, it would be fixed, as directly and
immediately as possible if there was high confidence. With less than high
confidence, maybe a quick test in a test environment is done. In many places,
this is now a multi-day, or even multi-week process now.

\- Developers are not all doing it because they love it anymore. It's a high-
ish paying job with lots of hiring being done. Many of the people writing code
these days are awful programmers that in the long run cause a lot of damage.
Many take away more than they add. In the earlier days, people coded because
they _wanted_ to.

The second problem is actually a big part of the cause of the first.

Perhaps I'm just bitter, but given the abundance of technologies, frameworks,
libraries, services, etc, small teams of _good_ coders can put together
amazing pieces of work in a very short time. This almost never happens. It
seems like complexity of large software projects has exceeded the ability of
the current level of general expertise to maintain. It sure seems like we're
close to that point.

I should add that I don't have the same opinions on most modern techniques.
Agile can work very well. Code reviews and unit tests are a must. These are
all tools that boost the quality and in the end, save time as well.

------
buboard
Ok boomer! that said I feel the same, having worked solo for 10 years. 99% of
the stuff i read about in this forum is about processes, management, code
review, packaging, testing, automating deployment. Who is doing the actual
building? It used to be that , with software, "processes" are automated
leaving you with only the highest-of-the high level entities, the code, which
is brief like poetry. Code seems less powerful nowadays, not a tool to create,
but hidden under layers and layers of process. I 'm kind of thankful i don't
have to work for others ever again, but i m also missing out on SV-level
salaries. How much time do people spend writing program rather than checking
in and out of various systems?

~~~
hootbootscoot
this.

and ultimately, who PAYS for all these deliberate hurdles and the deliberate
curtailing of human productivity to serve a tangential dubious (at best) goal?

~~~
marktangotango
Seems like a proof by existence about the predominance of BS jobs?

------
x3ro
I do understand the criticism of open plan offices and the resulting
interruptions, I do myself prefer a closed office. And I definitely haven't
been around as long as this person. That being said, it feels like this person
is just upset that they're not "at the top" anymore. Quote:

It was great back then; we were treated like princes [...]

------
jimws
Open space offices is another similar fad that I cannot stand. Who wants to be
at the constant risk of being interrupted and be distracted by side-channel
chatter!

The situation has become so bad that I cannot find many companies I can work
for that has not succumbed to this fad. The only workplace that works for me
now are the ones where I can work remotely.

~~~
RandomInteger4
Open source offices are a result of companies not willing to train. Everyone
wants to hire someone with experience in their tools, and also only hire young
people, so what are young people going to do? They're going to teach
themselves free tools.

EDIT: I'm apparently a blind idiot in the morning. Misread the parent comment.

~~~
ashildr
It seems autocarrot did not only change one word in the beginning your text
but fittet the rest of your text to find a new meaning.

~~~
RandomInteger4
My eyes don't work this early apparently. I completely misread the comment I
responded to.

------
robotron
"Refactoring" and "technical debt" are just faddish meaningless words?
Alright,buddy. From one old programmer to an even older one, you really are
just being a grumpy old man.

~~~
koonsolo
Fully agree with you (from a 40 yo). I really love the term "technical debt",
because it says exactly what it is, and can be communicated properly to
management. As long as you have debt, you will keep paying for it until you
pay it off. Very clear and precise, love it!

Refactoring a bit less, but it is also a very clear term so other people know
what you are doing.

------
wayoutthere
I think a lot of this is just a product of the amount of complexity software
is expected to manage. No single person can keep it all in their head with all
the constantly changing parts.

This has followed the shift of oftware development from a capital investment
to more of an operational one. The job profile of operational work doesn't fit
neatly within the solo developer / deep flow paradigm. Sure, that might be
necessary for _some_ dev jobs, but _most_ dev jobs are more figuring out what
needs to be built than actually building it. And for better or worse (usually
worse for those of us on the spectrum), every job seems headed in this
direction.

~~~
zozbot234
> the amount of complexity software is expected to manage.

How much of that is _incidental_ complexity, though? What happened to
refactoring and paying down technical debt - weren't these supposed to be
tenets of Agile?

~~~
wayoutthere
The best way to think of Agile is "bare minimum project management for the
sake of product management". You can get wrapped up in the rituals and "best
practices" but at the end of the day, it's usually about delivering software
in a way that makes it easy to buy and sell. It's easier to sell software when
you can pull a feature on a roadmap up to land a big account than it is to
refactor and cut a custom release for them. It's easier to buy software when
you know it's constantly improving.

Software also does more and integrates with more than it ever has. This is
driven by customer requirements, which are pretty much non-negotiable.

~~~
zozbot234
> It's easier to sell software when you can pull a feature on a roadmap up to
> land a big account

It's _initially_ easier to sell software with that quick-and-dirty approach,
but if you keep doing it you'll find that you're incurring a lot of technical
debt. Which you'll need to pay down in some way, if you want your software to
be "constantly improving".

If you're right that customer requirements are requiring more essential
complexity of our industry, keeping these dynamics in check can only be even
_more_ important, rather than less.

~~~
wayoutthere
> It's initially easier to sell software with that quick-and-dirty approach,
> but if you keep doing it you'll find that you're incurring a lot of
> technical debt.

Developers think a lot about technical debt as it relates to engineering (and
they should!), but I find that "product debt" (features that need to be
combined / streamlined / reimagined for UX / product purposes) is actually
more meaningful in most contexts. This can make conversations with product
folks difficult as engineering and a product owner often have very different
ideas about what the phrase "technical debt" means. It can be hard to pay down
either when you're talking past each other.

> If you're right that customer requirements are requiring more essential
> complexity of our industry, keeping these dynamics in check can only be even
> more important, rather than less.

The world is simply a lot more complex and interconnected than it was 20 years
ago when the type of development OP describes was still widespread. I don't
think we can put the cat back in the bag. Agile approaches honestly reduce the
complexity by not building anything that isn't being asked for and being
intentional about which tech debt to pay down.

~~~
pdimitar
> _Agile approaches honestly reduce the complexity by not building anything
> that isn 't being asked for and being intentional about which tech debt to
> pay down._

It can do those things, but it very rarely does, even by well-meaning teams.

It’s time to drop the “should help” and adopt the “...but historically, did it
really?”.

Changing that mindset I found to be a nearly impossible task.

~~~
wayoutthere
I think everyone wistfully pining for an era without Agile forgets how many
software projects were flat-out abandoned without seeing release after a few
years of dev work. Software development was not a "hot profession" until Agile
came along and a software product was no longer a multi-million dollar
commitment to get money coming in the door. We all owe the success of the
industry to Agile / iterative development, because most of the projects that
keep us employed never would have gotten off the ground in a pre-Agile world.

One of the oldest cliches in software development is "faster, better or
cheaper -- pick two". The prevalence of Agile basically means that "faster and
cheaper" is the default answer to this question. If you want "better," the
CMMI still exists (and is still heavily used in defense / aerospace).

~~~
pdimitar
I am strongly sceptical about Agile bringing about software development to be
the highly paid and somewhat prestigious profession it is today. I think it
was more like the pressure to have software do much more than it did before.

Agile is very likely to have played a role but I don't feel the correlation
between it and the current state of programming is that strong. There are
other factors that mixed with it.

What I will always agree with is that Agile / Extreme Programming brought
about much needed pressure to stop the waterfall approach in every single area
of engineering, programming included. That's the historical role I attribute
to it and for that I am very grateful.

Anything beyond that, I am fairly sceptical. Agile didn't really do _that_
much in the grand scheme of things.

------
mellosouls
Unfortunately some decent points are somewhat obscured by the condescending
and nostalgic tone that hits you in the first line:

 _Many too young to have ever seen the halcyon days of software
development..._

Every generation has blinkered old guys talking in that way, who can safely be
ignored. There has never been a more exciting time to code, especially away
from the corporate treadmill.

I particularly lost patience when he started talking about the Beatles (and I
love the Beatles). Mate, if you came of musical age in the early nineties it's
spelt _Nirvana_. Or _Wu Tang_. Whatever, he sounds like he was always looking
back.

~~~
coldtea
> _Every generation has blinkered old guys talking in that way, who can safely
> be ignored._

Can they? Here we are in 2019 and we're reinventing (usually in worse shape)
everything people already had in the 70s, 80s, 90s, even the 60s (Go is closer
to Algol than to a 2019 language, our IDEs are worse than LISP machines or
Smalltalk environments). We all use UNIX (a 70s technology), OS X/iOS (a
variation on a 80s microkernel + BSD), and Windows (a 30+ year old OS design,
from a prominent 70s/80s OS designer). We reinvented techniques used 40+ years
ago in mainframes as containers. Our UI tech of choice is the DOM...

> _Mate, if you came of musical age in the early nineties it 's spelt
> Nirvana._

So? I did, and they still have 1/10th the complexity and breadth and reach of
the Beatles. They're not better musically or lyrically or culturally or
production wise or music playing wise (so not in any way).

They're just closer to the age familiar to the 90s teens. So you're accusing
him of clinging to what he knows from his youth, when you're infact clinging
to an inferior standard (Nirvana vs Beatles) just because you know it from
your youth.

So even this makes the author's argument for him...

~~~
mellosouls
The Beatles: Firstly, you don't know what I know from my youth. Please argue
the point, not your presumption of my personality. He talks about them as the
heros of "our generation". They weren't. The musical heros of that generation
(in the sense of being the leaders of that time) included the ones I've
mentioned. The tone is nostalgic and rockist, as dull and unimaginative as his
tone when talking about coding.

Every generation reinvents stuff, and adds new inventions of its own. People
shouldn't just dismiss new creators as inferior out of some chronological
quirk, just because those people were born at a later time, or because low-
hanging fruit are gone. It's exactly the same condescending and arrogant tone
that consigns all young creative people to being "unlucky" to have been born
when they are.

Ironically, the Beatles - and the tech wizards of the past never listened to
that moaning nonsense either from their own older rose-tinted, time-locked
colleagues, they just got on and changed the world.

~~~
coldtea
> _The Beatles: Firstly, you don 't know what I know from my youth. Please
> argue the point, not your presumption of my personality._

You wrote: "if you came of musical age in the early nineties it's spelt
Nirvana", so one is entirely justified to argue based on that.

> _Every generation reinvents stuff, and adds new inventions of its own._

Well, that's the "everything is always the same, just with different flavors"
argument.

I don't buy it. In history (of science, art, inventions, etc.) we can see that
are long periods of stagnation, bursts of higher creativity, eras of
repetition, eras of exponential growth, etc.

~~~
mellosouls
_> You wrote: "if you came of musical age in the early nineties it's spelt
Nirvana", so one is entirely justified to argue based on that._

Of course it isn't justified to make that assumption, here I'll show you:

 _if you came of musical age in the 90s it 's Nirvana, Wu Tang, whatever_

 _if you came of musical age in the 60s it 's the Beatles, Motown, Rolling
Stones, whatever_

 _if you came of musical age in the 80s it 's NWA, the Smiths, Michael
Jackson, whatever._

You can surmise nothing about me except I have some understanding of pop
history; you are also reading into my first comment a comparison of worth that
is a separate discussion and not remotely connected to my original point.

To repeat: argue the point, not your presumption of the person.

As for the rest of your comment, I'd broadly agree with a suspicion of
relativism and your summary; but you are leaping from that to an unhealthy
dismissal of an entire generation - which attitude is generally associated
with the sort of moribund conservatism that all great talents - of whichever
decade or century - always fight against to the death.

------
loopz
People working on laptops like in that picture is unergonomic and
unsustainable. Say hello to back- and neckpains. Who pays for that?

The text was just a tedious hard-to-follow rant. Flow isn't that special: It's
a state of mind when you're engaged in relatively easy logical work, while
unsynchronized with other people's work.

~~~
zozbot234
You can synchronize with others' work without breaking flow. In a software dev
context, computer-mediated communication and review, proper issue tracking,
etc. make this a lot more feasible.

~~~
loopz
This _can_ be true, though so can collaboration in person also be. Often, time
pressures, office politics, culture, etc. get in the way, though can be
filtered to some extent through text media, but not without losing some
meaning, insights and opportunities.

Frankly, modern corporations only appreciate productivity, innovation,
creativity and spontaneous combustion, when executed at the dictate of
Directors. So whenever you found a sweet spot, know that Change (Winter) is
coming.

------
nickthemagicman
I'm totally ok with Standups as long as they're not every day.

I like working remote but I also like working in the office a couple days a
week to connect with my team members.

It's possible that these ideas taken to the extreme are bad but taken in
moderation can be great.

Open offices...are still the most horrible idea ever.

------
ykevinator
He is 100% right about flow. 8 hours of super quality concentrated high value
work with breaks is what everyone wants but no one gets.

------
purplezooey
_" The PMs were worse, putting on a perky, chirpy and cheerful show of
sounding “engaged,” when in reality I knew they spent most of their day
playing games..."_

Ayup....

------
luord
While I agree on a couple of things: Primarily how scrum and company are
complete bastardization of everything the manifesto stood for and that the
tall poppy syndrome against more dedicated developers by pretending they're
not "team players" or are "prima donna"s is absolutely ridiculous; that's
where my agreement ends.

Agile malpractices doesn't mean that writing software with more agility is
bad, and I found odd that he derides pair programming but at the same time
derides TDD because of the misconception that it means that a second pair of
eyes is no longer needed.

And, of course, the pretense that the biggest reason MS was successful after
it was no longer inside a garage was due mainly to anything other than scummy
corporate and monopolistic practices is... Suspect, to say the least. MS, from
all appearances, became awful once it was more than ten people, but that's got
nothing to do with agile practices.

------
RickJWagner
I love the look of the house.

About the life story, I never cease to be amazed at the level of personal
freedom offered by a career in programming. I have friends who move to far
away places, take long sabbaticals, etc. What a great thing.

------
tgv
Bit rambling, but it boils down to a critique of fad-driven management: we
have do TDD, Agile, whatever, but --from the developer's point of view-- more
as an end than a means.

------
7532yahoogmail
I've also been in software for many years. If I wanted to take aim at stupid
corporate America (when/where it exists) in software it's pretty easy to be
more damning than slashing agile's tire and running away. Btw we should
acknowledge that while hw gets cheaper and better, sw has real problems doing
the same. A better way to start don rickling software would be to start with
the Standish choas report from the 90s.

------
chrismmay
I hope younger devs keep in mind that one day you will be the "old" one.

------
heidar
The good thing about industry standard terms is that it makes it easier for
people to work together. As opposed to everyone coming up with their own terms
for things. To me that’s one of the big pros about agile.

~~~
thrower123
I'm not sure if it is better to have everyone use different terms for the same
things, or for everyone to use the same terms for different things. With
Agile, I feel like we are mostly in the second case...

------
vsareto
Usually the funniest thing about these posts is some kind of implication and
surprise that things would have stayed the same across generations

------
Marazan
'Flow' is the faddiest word in Software Development right now. My entire
company has managers talking about flow and rearranging time so that Engineers
can flow etc.

It completely ignores that masses of people do not work effectively that way.

In the field of learning people have long realised that sitting down people
for a 3 hour session learning doesn't work, it actively inhibits learning. Why
is it not the same for applying knowledge.

~~~
donatj
I work in the educational space, and I think, as education is discovering,
different strokes for different folks. Different people learn best in
different ways. Different people work best in different ways.

The problem is one-size-fits-all prescribed solutions, telling people how to
be productive. Depending on where a person is in a project, their mood, phase
of the moon, etc, they may be more productive collaborative or heads down. It
varies by person and time. I think there is room to respect how individuals
work best.

------
purple_ducks
Agreed 100%.

------
vaporland
yesyesyesyesyes

agree 1,000,000%

------
hootbootscoot
...look at all the babylon fans cheering the monster on. how dare a measly
lowly human have an opinion after personally suffering at the hands of
brainless machinery...

the thing is, it takes exactly zero courage or risk to cheer for the status
quo.

the other thing is, later we often realize that the system was wrong, and the
iconoclast was right.

where does the true arrogance actually lie?

