
The Quiet Crisis Unfolding in Software Development - Hates_
https://medium.com/@billjordan1/the-quiet-crisis-unfolding-in-software-development-cffbdafbf450#.4owgmm8hm
======
ricardobeat
> Odds are far better than good that your high performers are achieving what
> appears to be high levels of productivity by building technical debt into
> the application by taking shortcuts whether intentionally or
> unintentionally.

This does not match my experience in ~10 years as a web developer. I see most
of the technical debt coming from low performers, who take longer to deliver a
poorer product. Most high-performers perform well precisely because they have
mastered certain development processes, tools and good coding practices, which
results in higher quality code. I'm thinking this must vary a lot according to
your industry.

~~~
hibikir
I hadn't seen that type of 'high' performer much for most of my career, but
now I work at a place that appears to be plagued with them. I think some
cultural practices foster that bad behavior, common in places that move fast.

One of them is to value support and firefighting very highly. The best
firefighter is often one that is also the most familiar with the code, so it's
common to see amazing firefighters that are also your arsonists! But when you
don't track where the bugs come from well, and have little code ownership,
whoever writes the most code writes the most bugs, does more firefighting
later, learns more about the system, and distances themselves from the rest of
your developers that actually want the system to work. This also increases the
amount of tribal knowledge (as systems get quirky and badly documented),
making it harder for anyone else to seem like a high performer, as to make any
changes to anything that isn't new, you have to learn how the rest of the
snakepit works. And as you learn how it works, it gets bigger, because the
"high performers" are creating debt far faster than anyone else can learn it.

If bugs are treated seriously, tests are treated seriously, and how easy
people join a team is considered an evaluation criteria for the existing team
members, not the new ones, things are different.

~~~
jakub_g
> whoever writes the most code writes the most bugs

I'm experiencing this first-hand now. One colleague is writing lots of code
very fast. Problem is, this code is far from perfect, and I spend a lot of
time to understand it, and I find many bugs quite often. In the meantime while
I'm reviewing, the guy writes even more code...

~~~
fouc
Hopefully you're not merging the feature branch until it passes code review.
And if there are bugs, then you kick it back to him with all the comments you
made.

~~~
CaptSpify
In my experience, these types of employees are "too busy for that". And they
typically have the political clout that they can continue to get away with it.
I'm not saying it should be that way, and YMMV, but it's how I've typically
seen it play out.

------
dclowd9901
> These leaders should also be publicly recognized as such. Promote them to
> the job they’re already doing. This formalization makes it easier for them
> to assist other developers without hard feelings — it’s now part of their
> official job description! — and provides them with recognition which
> increases morale. Without that official recognition, providing assistance
> can often feel like little more than an unwelcome burden. Don’t let that
> happen to your employees.

Piggy-backing off of this astute suggestion, I'd also like to say that it
_signals_ to other developers in the org that the org appreciates and rewards
people stepping up. This can be hugely important for retaining talent -- it's
the difference between whether an employee thinks they have somewhere to go in
their current org, or if they have to leave to step up.

------
somethingsimple
I'd add one thing to that list: be wary of genius developers.

I currently work on a project where one of the most senior guys was an
incredibly smart person. He wrote extremely complex parts of the code that
"just work". The trouble is he's now gone from the team, and no one
understands why certain things are written the way they are, and people are
afraid to touch them.

Despite being really smart, this person was not very good at communicating.
Your typical shy and introverted little genius who does it all on his own.
When asked to explain things, he would just say "trust me, it has to be this
way", but wouldn't really explain why he made certain decisions or wrote the
code in certain ways.

So now we're in a situation where there are parts of the code we can't touch
because "he said it had to be this way". Great. I call it personality-oriented
engineering. A total failure.

This person got to a higher position because management only looked at how
smart he was and how he was able to deliver complex solutions that would
impress everyone. They failed to realize how bad he was at leaving a legacy of
maintainable code that can be moved forward.

~~~
tensor
I highly disagree with this.

There is such a thing as domain expertise. For example, machine learning,
compiler design, graphics programming, etc. If you are say, a web developer
these people might seem like geniuses to you, and no, you wont' be able to
pick up and understand their code. This isn't because it's not documented well
enough, or that it's not written well, it's because you lack the domain
knowledge to understand it. For example, I've written code that you absolutely
will not understand without weeks or more of study in the domain. The code is
documented, and has links to science papers that you need to read to
understand it. But know that you may need to spend _months_ to learn enough to
really know it.

It's not the responsibility of the domain expert to teach you an entire
domain. So yes, they may just tell you to trust them instead of telling you to
go study some volume of domain work. It would be better if they did the
latter, but I suspect that many here would still complain with that answer.

~~~
Roboprog
Agreed. Background / culture makes a big difference on how well devs can
understand each other's code.

I still wish more of my teammates (past & present) wrote more comments (as in
"statement of purpose", at the top of a chunk, not just "this part is
complicated", in the middle here and there) in their code, though. :-)

Anecdata: As somebody who did actual paid work in an interpreted / dynamic
language in the late 80s during and just after college, I seem to see people
who have only been through the C ... Java regime struggling with more "modern"
(? alternate, anyway) dynamic / functional scripting type languages. It's just
not something they are familiar with (intuitive = familiar).

Not that CSU did a _great_ job teaching FP in the 80s, but we at least got to
play with original flavor Lisp a few times...

------
emeraldd
"If design and code reviews aren’t highly interactive with lots of questions
and recommendations, your employees aren’t taking them seriously or they’re
too shy to speak up. Very often one or two developers are interested in them
but without obvious interest and input from the rest of the team even
interested developers will tend to severely curtail their questions and
recommendations."

This drives me nuts, it manifests itself in some many different ways: * The
"immediate" thumbs up on a PR * The PR that sits and languishes forever * The
chat room of silence when someone asks an architectural/design question

It can get really frustrating. Still no clue of a good way to fix it since the
problem stems from a long built team culture that needs to change.

~~~
philsnow
IANAM so grain of salt.

> The "immediate" thumbs up on a PR

This one bugs me too. Really? On a PR with 400 delta lines, you didn't need
clarification on anything? I don't know what action to take here.

> The PR that sits and languishes forever

Get your team to agree to an PR review SLA on the order of a day or two.
"Enforce" the SLA -- how you do this depends on your team and the situation,
but it can help to just remind people that they collectively agreed to the
SLA.

Suggest reviewing PRs with the same cadence as checking email (~1-2x per day).

> The chat room of silence when someone asks an architectural/design question

Identify one or more "natural leaders" as mentioned in the article, and
encourage them to check on the chat room periodically (email cadence?) to
route questions to the most likely person. They should know who that person is
because they're generally well-connected, and mentioning them by name creates
social pressure for that person to respond.

~~~
ChemicalWarfare
On the flip side - to properly review a 400 line pr would take hours unless
you were involved in discussions with the developer along the way like let's
say he's making changes to the api while you're working on the consuming
client.

I typically ask for the devs to push their code into the repo incrementally as
long as the change doesn't break anything. That way you have manageable prs
and if there's a need to go back to the previous version you have smaller
deltas to deal with as well.

~~~
crdoconnor
>I typically ask for the devs to push their code into the repo incrementally

That's fine provided each of those PRs gets reviewed and merged almost
immediately but if you don't do that then either the developer has to create a
separate branch for each incremental improvement (horrible) or let them mount
up into a monster pull request (also horrible).

Some changes also kind of need to be large in order to not break anything
(deep architectural changes).

~~~
ChemicalWarfare
Yea speed is key with incremental prs. Which is on me most of the time as a
lead SA on the project. I encourage the devs to slack me directly or drop an
@here note in one of the relevant channels. I do the same when submitting prs
myself too.

------
NKCSS
The best piece I've read on the subject; I agree with everything he has
written and it's the stuff I've told management at many companies I've been
at. I've yet to see any of them listen to me though; usually, if they don't do
things the way outlined here, they just don't get it and the offered reasons
will not resonate.

~~~
geoka9
I agree, I could have written the same essay myself!

Except for the last point:

> but a nice pair of jeans and any decent shirt with a collar should do just
> fine.

Why should there be such a requirement? Why can't people wear shorts and/or
t-shirts if they want? Of course there should be some requirement (like having
some kind of clothes on) but otherwise I don't think any code is necessary as
long as the team is comfortable.

~~~
NKCSS
I understanding where you are coming from; I thought the same when I was a few
years younger and was wearing t-shirts with texts like "not even Norton can
protect you", "every time you download music, God kills a kitten" and "I read
your e-mail". And while those are a lot of fun, it's not fun to explain to
customers and have to say: "Don't mind them, they are just our developers..."

~~~
douche
Question: Why are your customers seeing your developers?

~~~
vigilant
The idea that developers should be hidden from customers, like lepers, is
offensive to me as a developer.

~~~
Gibbon1
Compartmentalizing workers from each other and from customers is a means of
control. Specifically management is trying to make sure that their developers
do not get exposure to internal or external groups that may try to hire them
away. Or give them a job if they get fired or laid off.

Consider

Case A: Customer knows you well understands you are competent. If you want to
leave or are laid off that customer might eityher hire you or know someone who
does. Or at least will give you a solid reference.

Compare with.

Case B: Customers and others only know you through your boss.

~~~
TeMPOraL
That's probably relevant only to the companies that work in the same field as
their customers. But there's another issue that applies to all: it makes that
layer of managers _relevant_. If they'd let the developers talk to the
customers directly, they wouldn't be needed anymore.

------
rcarmo
The open space bit keep nagging at me. I've liked and hated it in equal parts,
but the truth is that as soon as I was able to spend time working from home I
stopped wanting to go to the office daily, period. I'm so much more productive
when not sharing a table with a half dozen folk.

~~~
bayonetz
Open floor plans are ~80% of the time about cutting cost but only about ~20%
of the time is this actually admitted by executives. There are plenty of
problems at my current job but being cattle caged in an open floor plan is not
one of them. Almost 100% of the time my introverted self performs an order of
magnitude better within the sweet sweet sanctuary of my door-locking, fully-
enclosed, window-with-some-mountains-in-the-background office. To the point of
feeling golden handcuffed by it. I'm sure I'm not a minority in this. I wonder
why more companies don't pay the extra, yet in many cases workable, expense.

~~~
virgilp
Which is stupid. You pay me a fuckton of money, do you want me to spend time
chitchatting about trivial stuff with the rest of my colleagues, or
implementing features you need to release? What is really more expensive, the
floor space or the lost productivity? (double-bonus points when you work in a
"low cost" geography but still use open-plan office because US uses it and
this is the corporate standard)

------
Bahamut
I like this article on a whole, but I do have a comment on this quote

> Optimizing for the common scenario means giving developers primary ownership
> of portions of the code base and not allowing other developers to change
> that code without approval from the primary owner. This results in higher
> productivity since any given developer is more likely to be familiar with
> the code in which they will typically be working.

I have worked with someone overly protective of the code sector he wrote, but
it has caused problems since I would like to fix some bugs in the API
signature of that code, but the developer has stonewalled me in the past &
raised a ruckus when I filed PRs to fix some of it. If it is something that
affects how other people interface with a feature, IMO it is not a good thing
to necessarily designate a primary owner & mandate all changes go through
him/her. Granted, some of the problem is that the other developer probably was
in the wrong being obstinate, but you work with the cards you're given.

~~~
mmatants
It makes sense to have centrality of vision for how code should be laid out.
This is software architecture (as skill and role, not title though!). And as
people have a limited focus span, it makes sense to segment - by business
topic, by API, etc. But of course fiefdoms emerge.

In some ways, it might then almost be better to not have that person
contribute to same codebase: to avoid ego pissing contests and to keep the
opposing pressures in balance. The pressures being: delivering features on
time on one hand, and keeping things clean and orderly on the other hand.
Often, if the architect codes then they can't see their own mistakes, but have
20/20 vision of others' grubby flaws, and hence gain subconscious animosity
towards external contributions.

That being said, an architect who does not code is even worse! This is where
we get ivory tower Architect-as-title, and even less gets done. I wonder what
the optimal middle ground is.

~~~
davidjnelson
Perhaps the middle ground is a software architect who codes, yet has high
emotional intelligence and acts as a servant leader. Someone who honestly
wants to help their teammates, and doesn't feel "better than them".

Perhaps they lay out a system design as a suggestion on a wiki and ask their
teammates including themselves to collaborate on it until everyone's content
with it.

Then perhaps they code a particular layer primarily and are humble and open to
criticisms and mistakes they make in their own coding. They understand that
they and others are not perfect, nor is the code they or others produce.

That and good relationships and communication with the product, design,
management, qa, and support teams are what I feel would define a valuable
"Software Architect".

------
Myrmornis
> Despite there not being a single shred of scientific evidence in favor of
> open office workspaces being a good idea and overwhelming evidence in favor
> of them being counterproductive for most software developers, this
> unfortunate fad is currently widespread. Software developers need private
> workspaces to ply their trade.

Yep. Perhaps this could be softened a bit to say there are different sorts of
devs, some seem to work OK in open plan offices and some need private work
space. But personally I'm in the latter group. My company moved to open office
space and I've come to not even think of the office as a place where I get
real work done. Thankfully they allow me to work from home as well, that's one
of the main things I'll be looking for in future employers. I have to admit I
can produce a feeling of moderately intense anger by just thinking of the
Yahoo executive banning work from home because she believed that everyone's
job involved frequent impromptu hallway chats or whatever the fuck.

------
zepto
"Don’t have Stupid Dress Codes" is then followed by a dress code:

"For some of them that’s jeans and a basic collared shirt and for others it’s
business casual."

Which for the author's arbitrary reasons leaves out jeans and a t-shirt -
although this guy makes some good points, this one is a bust.

~~~
deckard1
yeah, that comment really seemed to show how out-of-touch the author really
is. I haven't worked in a place that required a collared shirt in more than a
decade. The last few interviews I've had, the interviewer wore a t-shirt and
jeans.

~~~
jake_morrison
He works in a consulting company in Texas. You need to project a certain level
of professionalism to make your customers feel comfortable. Sometimes looking
weird can be positive, e.g. for designers, but it can be a distraction.

------
dpeterson
"Odds are far better than good that your high performers are achieving what
appears to be high levels of productivity by building technical debt into the
application by taking shortcuts whether intentionally or unintentionally"

This is repeated over and over in almost every management book; managers are
starting to believe it. In the book "The Phoenix Project", Brett, the most
technical guy, was the high performer to fix almost everything. The moral in
that story was that Brett was also the Fire Starter. No, management need to
feel high performers below them actually belong there. Unfortunately technical
skills fade and once good managers become bad and incompetent. Worse, most
technical managers were never technical. Just this week I had to put out a
fire most certainly not caused by me or my code. I inherited a mess from
outsourced workers. Any requests to improve the code base were met with
disapproval. Some of our custom code interfaces with an external system that
has an API. When we upgraded to the latest version of the external system; it
became more strict on what it allowed. To help with the migration, management
paid many thousands to have three "experts" on the system come in and help
make transition to the new version go smoothly. I was not on the migration
project. However, when sh@t hit the fan I was called in. Testing was poor and
they went live. The three experts could not find the cause of major problems
and certainly no one else on the team was willing to step up. I had to spend
the entire week becoming an expert on the external system and quickly fix the
problem. Yes, I am a high performer and I did not cause the fire. It is
because I roll up my sleeves, get to work and never give up. I'm sorry if that
scares some management. That they actually need some people.

------
tetraodonpuffer
excellent article, it is especially interesting the advice on being liberal
with promotions and technical career track, given that in several companies
I've worked for when you get to a certain level (principal/staff/lead/...
whatever) getting promoted further is an exercise in frustration, because
either there are only X slots (we can't have more than X fellow positions in
the company) or it becomes a matter of having to play politics, or you end up
in companies where the technical ladder has a (sometimes low) glass ceiling.

I would've added a paragraph on stack ranking and curve ranking in general,
which although obviously extremely detrimental to morale and retention, still
unfortunately rears its head at times, and one about how to handle
layoffs/restructurings as those are not easy to do well.

------
skybrian
Sensible advice, but I didn't see anything about a quiet crisis.

~~~
emeraldd
The crisis is that software shops are ignoring the basics and pushing "fadish"
solutions:

    
    
      "... I’ve noticed a quiet crisis unfolding in software development leading to low quality applications, unhappy employees and unhappy users. Silver bullet solutions keep creeping into our awareness (Scrum, anyone?) and predictably keep letting us down.
      This is almost entirely the fault poor management — or perhaps it should be called fad management."

~~~
deckard1
Nothing has changed since Fred Brooks wrote The Mythical Man-Month.

Fads will always exist as long as someone benefits from selling the fad. And
there is _always_ someone selling shovels in a gold rush.

------
snarfy
I think the crisis is bigger than software development. It's evident at all
levels of society.

There is a real lack of leadership in the world.

Everybody is so averse to risk and afraid to follow their own beliefs that
they end up doing what everybody else is doing. That is not what leaders do.
This is how we end up with scrum. It's also how we end up with partisan
politics, a dozen sequels of the same movie, and nickelback.

------
vigilant
There seems to be a lack of emphasis on 'shipping working software' in this
list. As a developer, that is what I ultimately want to be judged on. Nothing
else. And too many managers judge developers by how closely they adhere to
their silver bullet development process which they read in a random website.

It seems like the only ways to do this are

1) Create a startup, ship something awesome, have a great exit 2) Work for
wall street, in a position where your success is judged by how much money you
make, which directly drives your bonus.

~~~
crdoconnor
>There seems to be a lack of emphasis on 'shipping working software' in this
list. As a developer, that is what I ultimately want to be judged on.

I'm not sure I do. Shipping software in a mess of technical debt is _much_
slower than greenfield development or development on a well architected
product.

I'd ultimately want to be judged by an architect who reads all pull requests
and understands at a deep level how all of the code fits together.

------
partycoder
If you pick your utility functions poorly, people start adapting to them with
unintended consequences:

\- Burndown charts: Burn lots of tasks fast, even if you are creating more
work in the process.

\- IBM once rated employees based on added lines of code. The result? An
explosion of code. Even code that wasn't strictly necessary.

\- Stack ranking: punish the lowest 20%, reward the top 20%. Sounds reasonable
at first, but what happens when employees adapt to it? People stop hiring
strong candidates. So over time, when people leave, their replacements get
worse over time creating a downwards spiral of worsening talent.

------
sbmassey
This is a good analysis, but it needs a silly name to be accepted as a new
management trend.

~~~
ClassyHacker
Software Development Management for Dummies

~~~
davidjnelson
I like that :-) To rearrange the letters slightly for a better acronym;
"Managing Software Development for Dummies", or MSDD ;-)

------
eistrati
This resonates with my experience. I agree that it requires a weird name to
start productive conversations :)

------
20years
Lots of good points here. Limit Interruptions and Prefer Private Workspaces
are big ones imo. If only companies realized that those 2 things can increase
production and output 10 fold. Sure open offices are cheaper but you are
paying for it in other ways.

------
twa927
There are some fine insights but generally it's the old view of managers vs
programmers as passive workers. For example, the advice for managers to
encourage programmers to do refactoring as part of normal (business-oriented)
tasks is skewed. It's programmers who know the field and they should have some
power to give refactoring tasks the same value as business-oriented ones. They
should be _partners_.

My view is also probably skewed compared to what a typical "software
development" company does, but I don't believe that Google or YC startups do
this kind of management.

------
scott_wilson46
This all seems highly sensible advice to me!

------
mempko
The real crisis is that people are NOT willing to create new software. And I
don't mean the "bag of libraries" that much of software seems to be.

------
maxxxxx
"at a minimum each developer should have a cubicle with high cube walls and a
small entrance"

Sounds more like a prison cell. How about daylight or a window?

------
BlaneG
Great article. I thought the title was pretty misleading though. My
suggestion: Advice for managing succesful teams.

------
adamconroy
Quietly unfolding? This has been going on for decades. In fact I think it's
prevalence is less these days. Not that I think the avg quality is constantly
improving.

~~~
partycoder
I think right now it got out of hand. With a lowered entry barrier to
development, now a regular code base feels like reading
[http://thedailywtf.com/](http://thedailywtf.com/)

There's now a social network for developer rants:
[https://www.devrant.io](https://www.devrant.io)

~~~
adamconroy
I guess its a subjective thing, depending on where you have worked and with
whom. I'm pretty picky where I work these days, so maybe I haven't witnessed
what you are talking about.

However I think these days, at the higher end of the spectrum, the general
awareness of good programming practices is better than it was 25 years ago.
Back then, unit testing frameworks weren't a thing, I didn't see any CI, often
code repositories were zips on a file share..., patterns were barely a
thing....

------
swehner
It's almost as if the crisis is all these people that think this or that
little item, feature, observation, insight, idea, etc. is soooo terribly
important.

------
eofear
I was agreeing with all his points until he decided to ban ripped jeans !!

------
bettyx1138
this is the best work-related article/essay i've ever read since i started in
this field in the 90s. (except for the _collared_ shirt part lol that's odd.)

