
The Eternal Struggle Between Business and Programmers - reforge_reborn
http://blog.thecodewhisperer.com/2013/11/11/the-eternal-struggle-between-business-and-programmers/
======
rayiner
Part of the problem here is that developers don't do a good job of creating a
culture that values refactoring as a key part of the overall process. The
underlying issues are not, at a general level, unique to software. It's not
like the business folks at GE aren't asking for more features faster. However,
other engineering fields have done a much better job at making things like,
e.g. testing, a core part of the culture. GE doesn't ship a refrigerator
without incredibly extensive testing, not just because of the threat of
lawsuits (another thing software developers don't really face), but because
the relevant engineering bodies have made testing a non-negotiable part of the
process.

From a manager's point of view, there's a big difference between having to say
"our engineers would like some time for refactoring" and being able to say
"refactoring is just part of the process--any other engineer would tell you
the same thing."

~~~
jt2190

      > Part of the problem here is that developers don't do a 
      > good job of creating a culture that values refactoring as 
      > a key part of the overall process.
    

And developers won't get a culture that values their work as part of the
overall process until they're promoted into positions with enough authority to
ensure that engineering processes are valued. There's so much management
bashing in the community that I fear that we've become self-defeating: The
only way to get better management is to promote managers from our ranks, yet
we're quick to put the "pointy-haired boss" label on anyone who dares to make
the move.

------
mattgreenrocks
It's worth noting that all three parties (devs, business, board/management)
are acting out of fear. It's little wonder that the outcome is poor.

* Management needs to get over itself and have a true vision beyond, "omg competitors are making money...more features!" that it conveys to everyone.

* The businesspeople need to absorb some of management's anxiety (and their own) on behalf of devs, and communicate with customers to ensure the vision aligns with what they want.

* The developers need to stop whining, up their game and go a bit slower so they don't get themselves in these situations to begin with. Give them what they need (quality code) not what they want ("anything that works NOW!!").

The business world seems rife with people who are purely reactionary, and yet
still have the gall to wonder why they cannot innovate: "We don't have money
for R&D!" OK, you don't have money for growth then.

~~~
etler
I think a big part of the problem is that nobody ever teaches developers how
to estimate and they are almost always wrong. A typical scenario is; PM
describes a feature, asks for an estimate, and the developer gives it to him,
right then and there. What's wrong with that? The developer hasn't done any
research or exploration into the problem at all, and has no idea what he's
talking about.

When you think of a time estimate, you're going to come up with a time
assuming that the problem can be solved in the most obvious way, and that's
because we can't possibly know about the problems we don't know about. It's
not a terrible crime to not know things you don't know, but it is bad to make
time estimates on things we don't know.

The correct answer is "give me a few hours to a day to look into the problem
and I'll let you know how long I think it will take". The amount of time it
takes for discovery depends on how big the feature is of course, but the point
is you need to get your feet wet to determine what unknowns there might be,
and you shouldn't give an estimate until you have done that.

~~~
bippi
I applaud the thought, but then they have to have an estimate of how long the
estimate will take... which often ends-up wrong.

~~~
etler
That's true :) But at least the absolute amount wrong will be hours or days,
instead of weeks or months. Also, you can leave it a bit more vague and just
say "I need to explore the problem space a bit before giving an estimate".

------
jtheory
This is a vague discussion that stays at a high level... I'm not sure how
valuable this kind of generalization is.

The "programmer" side of this discussion certainly does _not_ always have a
grasp of the needs of the business in mind, and it doesn't help that
estimations of effort for new features (or refactoring efforts, even minor
ones) are notoriously difficult. Some programmers are business-savvy, but most
really aren't -- not necessarily due to ignorance or inexperience! It takes
significant effort & time to keep a finger on the pulse of a business, to
really know how much _this_ contract matters in the grand scheme, what's
_really_ required to land it, and when.

So it comes down to communication, and different people figuring out what
actually needs to be communicated, but that's so relevant to everything it's
almost useless to say.

Case studies would be more interesting -- real ones, inasmuch as that's
possible without making real people look bad. The author seems to consult on
this sort of thing for a living, so that's probably possible.

~~~
ChuckMcM
I read the article to be a light approach toward the question of 'What do
managers even do?' because it seems managers spend much of their time
balancing those two demands (features / technical debt).

------
bowlofpetunias
One major problem with this: Business lies.

Not maliciously, it's just the way they do things. They think they're
negotiating instead of cooperating. If they really need feature X in 6 weeks
time, they will tell the Programmers they need it in 4 weeks.

Programmers however will be honest, and worse, _optimistic_. When they say it
can be done in 8 weeks, 10 weeks is probably more realistic.

That huge difference removes all the room for coming to a mutually
satisfactory compromise.

Even if both sides agree on a compromise, the Programmers will be fucked. They
only difference is that they've fucked themselves, but since in the end it
will come out Business "lied" (we all know it, the moment we delivered just in
time, and nobody cares for _weeks_ ), they will still blame Business.

Business and Programmers need an interpreter that doesn't take sides, but hey,
we just figured out management is useless, right?

------
rumcajz
One thing not to forget is that if you unleash refactoring on a grand scale
you'll end up with second version syndrome.

Thus, management has a problem. To allow refactoring, they need to believe
there's a technical person in charge that is able to keep the refactoring in
check. But, as a manager, how would you asses that?

~~~
icebraining
Isn't the solution to allow very regular (daily?) refactoring, instead of
pilling new stuff for weeks and months and then having a big refactoring
party?

------
baldeagle
I've always wondered why, in a company that loves 6 sigma and other process
improvements, we never really got behind refactoring code. I mean, cleaning
the flow of books and nuts through the line is praised, but the flow of an
array through logic is not. I think it has to do with the former being easily
seen - physical and the latter being abstract. It could also have to do with
easily proving repeatability... It is easy to see that the bolts will be
installed 500 time in a week; less so about the logic. In fact, I think if we
could show measurable velocity improvements from refactored code; it would
show business how investing in refactoring pays off. Kinds like a Toyota
production system for c++.

~~~
pekk
I'm agreeing with you. It has to do with code not being visible _to
management_. That is intentional, management doesn't want to see or think
about code. They want to push that entire concern to the technical team and
never see it. Which is reasonable enough. Then they have a time demand or
feature demands (which amount to the same thing) and suddenly the technical
team doesn't see a lot of breathing space to work on code quality. If
management trusts a credible view expressed by the technical team or the
technical team can irrefutably prove that the added time will improve some
metric of business interest then this can change.

------
buckbova
> The Business needs to agree that the Programmers have heretofore gone more
> quickly than they really can, that they cannot sustain this pace, and that
> to do so merely hastens the ultimate decline of the entire product line, and
> perhaps the company.

Yes the business agrees, but then continues to demand new features. Nothing
changes until the people change, code is tossed out, and the whole thing
starts over again.

------
bippi
My most heartening point of this post and story, is that there are only 21
comments as of this post (22 after I hit 'enter'). So, while I sourly identify
with this piece and want to post it outside of my cube wall... this isn't
garnering nearly the crowd of other universal HN siren songs.

Phew.

------
ale7714
The timing of this post is great! So tented to send it to my boss who
apparently has no clue in software engineer. Great article! Recommend it!

~~~
baldeagle
As a mostly business guy, I kind this post said it best. It is about velocity
and when to tractor/automate. It came across HN a couple weeks ago, but I'm
not great at searching HN. [http://blog.hut8labs.com/speeding-up-your-eng-org-
part-i.htm...](http://blog.hut8labs.com/speeding-up-your-eng-org-part-i.html)

~~~
nlawalker
Thank you, this is fantastic. I'm now thinking of ways I can transform this
into a short presentation.

------
michaelochurch
This is a pretty shallow analysis, and I don't find it useful.

"The Business" is mostly full of non-technical people who, while they might
not be analytical or even as smart, but who understand politics well and know
how to solve the local optimization of seeking their own careers and power.
They don't want "more features! now!" Their motivations are things like (a)
making their mark, (b) concentrating a power base, and (c) tying their names
to an obvious, low-risk opportunity for visible gain. The reason they want
"features" is that everyone who gets power needs to use it to make some kind
of mark in order to retain that power. Programmers tend to underestimate
"business idiots" while refusing to acknowledge that those "idiots" being in
charge means that they're good at _something_.

Programmers don't want "more refactoring!" out of some knee-jerk
defensiveness. The good ones want _technical excellence_ , which dies in
deadline culture. They want to build things they can be proud of. And there
are careerist reasons for them to feel this way, because tech gets shit on as
soon as things go bad, no matter who's really at fault. If you build a system
that generates $50 million per year, then make a mistake that causes 4 hours
of downtime ($23,000 loss) of that system, you'll typically be mortally
embarrassed and possibly fired. So, programmers have solid,m career-oriented
reasons to push back when asked to do something in a quick, sloppy way. They
(and not the managers who ordered them to cut corners) will be the ones to
suffer when things fall apart.

The hard and painful truth is that business-oriented programming is
underappreciated by business and unattractive to talented programmers, and so
almost a complete non-starter. The good people tend to fight for a while (for
more refactoring, more autonomy) but eventually disengage or go elsewhere
(e.g. consulting, where there's an outside chance of getting what they're
actually worth). The bad programmers don't care about "refactoring" per se but
have learned how to parrot the good ones. Thus far, VCs have tried to overcome
this problem (the complete non-viability of business-oriented programming)
with the smoke-and-mirrors show of startups and paper millionaires, but the
wiser people are starting to figure that one out, too.

For the record, there isn't a huge mismatch between "The Business" and "The
Programmers". Great programmers are _perfectly happy_ working for the
business, if compensated appropriately (see: quant traders at hedge funds) or
if they own it. They just don't like working for the business _as a
subordinate_ , because it leads to spending a lot of time implementing
_stupid_ features that obviously don't make sense or deliver value to the
company, but that meet the parochial needs of a specific ambitious executive
(who won't protect them in return for their service).

~~~
buckbova
Well said.

> The hard and painful truth is that business-oriented programming is
> underappreciated by business and unattractive to talented programmers, and
> so almost a complete non-starter. The good people tend to fight for a while
> (for more refactoring, more autonomy) but eventually disengage or go
> elsewhere . . .

I'm at the "disengage" point. The higher ups aren't heeding my warnings that
what we are doing is not sustainable. Eventually the system will enter a
permanent broken state and I just don't care anymore.

