
One cost engineers and product managers don't consider - jkopelman
http://firstround.com/article/The-one-cost-engineers-and-product-managers-dont-consider
======
nhashem
_For years, the two things that most frustrated me to hear from product
managers were "how hard would it be..." and "can't you just..." It took me
quite a while to figure out why I had such a strong, visceral reaction to
these phrases._

Oh, man.

When it comes to my natural reaction to this, the words 'strong and visceral'
doesn't even do justice.

It took me a really long time to understand why I had such a deep-seated
_loathing_ for phrases like that. Think of some absurd scenario where someone
asks you to cause harm to yourself, so they can benefit in some way, and
that's how I would respond. I basically translated these requests to something
like, "can't you just shoot yourself in the foot, so I can sell your toes?"
and reacted accordingly.

This post provides some good examples -- explained in a much more objective
and rational manner than I've been able to -- of the cost, and why this
bothered me so much. In general though, if engineers have to spend a lot of
time mitigating "can't you just...?" then I think it may point to a more
systemic problem in the organization. Namely, the business units are so
disconnected from engineering they don't even realize the costs of what
they're asking for, and the engineers are so disconnected that they reap zero
benefit from whatever business goal is going to be accomplished by this.

I'm actually okay with shooting myself in the foot to sell my toes every once
in awhile. I just don't want to do it if everyone else is going to make money
from selling my toes except me, and they don't care about giving me time to
rebuild my foot afterwards.

~~~
mgkimsal
"Namely, the business units are so disconnected from engineering they don't
even realize the costs of what they're asking for, and the engineers are so
disconnected that they reap zero benefit from whatever business goal is going
to be accomplished by this."

I don't think it's just that they're disconnected - some of the orgs I've been
in - they simply _do not care_ , and never will, even if they completely
understand the "costs". Why not? Because they don't have to pay it. It's not
coming out of their budget, the 'costs' of higher support later on don't
affect anyone who's making the decision right now, and damnit, we have to get
this out _now_ or we'll lose marketshare!

This is a toxic division, and seems to be more prevalent at companies that do
not see themselves as software-based companies. Yammer is all tech - Yammer
couldn't have existed 30 years ago, but plenty of more traditional companies
still see software as something divorces from their main business.

~~~
mason55
It happens in tech companies too, especially enterprise companies. Project
managers want to close out on their project and deliver to their customers and
fuck anything else that's going on.

------
RyanZAG
Good article, makes an important point about complexity.

Just want to add one extra thought though:

    
    
      he or she will run reports against the usage data to find
      out whether a given feature is often used. That data can
      then be run past the product managers who can help decide
      whether it's sensible to just drop the feature. 
    

It's important to be careful here, and it's one of the traps that is very easy
to fall into (see Gnome). Just because a feature is only used by 1% of your
users doesn't mean it's not important. You might have 100 features only used
by 1% of your users each, but if you take out all 100 features, chances are
you've taken out at least one feature that every single one of your users
depends on, and now your product is a lot worse instead of better.

~~~
RyJones
We hit this at MSN: we removed the "print" button from all articles. Result?
Engagement in Japan fell. Why? Apparently, printing out a sheaf of articles to
peruse on the train is (or was) a thing. Solution? Re-enabled the "print"
button in Japan; everyone else was saved from downloaded the unused-in-market
"print" button, lowering PLT.

Please keep in mind I'm talking about stuff from about five years ago when you
run to MSN.jp looking for print buttons.

~~~
smartician
Problem is then that you have two cases that need to be tested and taken into
consideration when designing etc.

------
russelluresti
The title of this article doesn't make sense to me, as an engineer, working on
a team of engineers.

Complexity is always something we consider - in every team I've ever worked
on. DBA's always talk about the complexity of the data. Dev's always talk
about the complexity of the code base. And UI Dev's and Designers always talk
about the complexity of the UI.

No one understands the cost of complexity better than engineers. We understand
the increase in the likelihood of bugs, or the increase in maintenance and
refactoring costs. We understanding that making a UI complex means users may
have difficulty learning how to complete a task and get frustrated, and we
understand the costs of those frustrations.

I'm not sure why this person thinks engineers and product managers don't
understand the cost of complexity. In my personal experience, it's always been
business and sales people who don't understand how adding a shiny new feature
could be harmful in any way.

~~~
rustynails77
As an engineer, my personal experience is that most feature creep actually
comes from engineers. Marketing usually have the least idea, but engineers
usually cause the "death by 1000 cuts".

~~~
russelluresti
I think the only time I've seen engineers add feature/code creep is when it's
"filling the gaps" that others didn't think of. Many times ideas are presented
to engineers in their unfinished format. It's often up to engineers and QA to
find the areas where that idea needs to be fleshed out. Fleshing out an idea,
I would argue, isn't feature creep but trying to make an added not suck.

~~~
Pxtl
Yup. When you've got a system that, as implemented, gets you 99% of the way to
a nifty but unrequired feature? It's dreadfully tempting to go that last 1%.
But somehow that 1% balloons into being something that you have to support and
the UI turns out messier than you expected and yadda yadda yadda.

------
emingo
The first comment on that page sort of made me face palm... but then it got me
thinking.

"Simplicity of usage should always win over simplicity of coding. The purpose
of a product is to solve the end user's pain, no one should give a dime about
the engineer's problem. IMHO that was the genius of Steve Jobs, he could take
any pre-exiting product and increase its complexity by 50x while simplifying
its usage by 10x."

I am relatively new to coding, and really, I want to know what do you guys
think about this? Does this really scale? Does simplifying the front end often
compromise the backend?

~~~
swalsh
Its a false duality. It assumes complexity is zero sum, either the user has it
or the programmer has it. In my experience this is not true.

~~~
Ygor
But, doesn't maintaining both implementation complexity and product usage
complexity low require either more development time or better developers?

~~~
sliverstorm
Reducing either form of complexity certainly costs resources, but I think the
point is that they are not necessarily antagonistic goals- they might even
come as a package deal, to some degree.

------
kfcm
_(5) It is always possible to agglutinate multiple separate problems into a
single complex interdependent solution. In most cases this is a bad idea._

\--RFC 1925,
[http://www.faqs.org/rfcs/rfc1925.html](http://www.faqs.org/rfcs/rfc1925.html)

I highly recommend reading RFC 1925: The Twelve Networking Truths. It's a much
faster and more amusing read to get the same information.

------
DanWaterworth
In my experience, practically everyone agrees that software should be simple,
but not everyone agrees on what simple is.

~~~
obviouslygreen
Unfortunately, that hasn't been my experience. Everyone wants software to be
_easy_ , but most people (by which I mean clients, management, and anyone else
who's ever asked me to build software) have no opinion one way or the other
about simplicity: They want it to do exactly what they want, the way they
want, regardless of how technically feasible or user-friendly that ends up
being.

Simplicity is an ideal I see a lot more among tech people (myself included),
and while I think it's nice to aspire to, it's definitely not something I've
seen as a request, requirement, or even preference among the kind of people
who are willing to pay others to build things. They want what they want, not a
simple implementation of what they need.

~~~
DanWaterworth
Perhaps the reason I haven't shared your experience is because I primarily
deal only with tech people.

------
ChuckMcM
Wow, that one really resonated with me. I hadn't really thought about how to
put simplicity into perspective quite like that. One of the things that
frustrated me about Windows was that there was always about 7 different ways
to do the same thing (or get to the same place) and that lead to amazing time
wasting discussions in attempting to support customers remotely.

Google has (had? I suspect they still do this) company wide 'fixit' days where
people would fix bugs for prizes and what not. I suspect a 'delete-it' (or
'simplify-it') might be a useful exercise as well.

~~~
zaphar
We still have fixits and we also have delete-it's as well. The team I'm
currently on has Delete Tuesdays where everyone competes to delete unused code
or config options. It's very satisfying.

------
kryten
Whammed in the face with:

"Subscribe to receive future articles right to your inbox"

Tab closed. To hell with them.

~~~
andrewcooke
something in one of chrome, ghostery, disconnect or adblock removes that, fwiw
(and maybe it's just because it's timely, but it's actually one of the better
posts i've read in this kind of thing).

~~~
kryten
I have adblock and ghostery. It still appeared for me.

Perhaps I should use noscript as well :)

~~~
foobarian
I rarely see this stuff in w3m ;)

------
michaelfeathers
I've been pushing this idea for the past couple of years with clients, and
when I give talks at conferences. The fact of the matter is that unless an
organization knows what the carrying cost is for their features, and the
effect in terms of complexity, they are flying blind.

In essence, it is Joel's Law of Leaky Abstractions at work. You can't manage a
software project just in terms of a set of features you agree upon with
business. The codebase is a key constraint that underlies all of those
discussions and unless the effects of feature choice are on the table, you end
up incurring radically different costs.

This isn't just about paying attention to technical debt. It's about having
the discussion about whether it is worth targeting some features or not,
taking the code into account - using it as a factor in business decisions.

[http://www.confreaks.com/videos/717-rockymtnruby2011-opening...](http://www.confreaks.com/videos/717-rockymtnruby2011-opening-
keynote-code-blindness)

[http://michaelfeathers.typepad.com/michael_feathers_blog/201...](http://michaelfeathers.typepad.com/michael_feathers_blog/2011/05/the-
carrying-cost-of-code-taking-lean-seriously.html)

------
itsybitsycoder
Totally agree. The last company I worked for would agree to add basically any
feature someone requested, even if it was of no use to anyone else. Most of
the time spent implementing these odd features was making sure they'd work
with all the other possible combinations of odd features, just in case they
were ever used in tandem. They never were. The project I worked on was in its
4th total overhaul when I left, and they still hadn't actually _sold_ a single
copy.

------
Domenic_S
An oddly lengthy article considering its topic (simplicity).

Useful nonetheless. It puts into words the visceral reactions we have all had
at some point to "How hard would it be to...?"

------
pedalpete
Would anybody speculate that the popularity of MVC and agile development has
exacerbated this issue?

I'm working for the first time on somebody elses code and with a group of
develpers, and it seems like the answer to most problems is 'just add another
model'. I stay away from that as much as I can, and try to make existing
models fit new features and functions.

Maybe it's just my current workplace, but is this a more modern problem?

~~~
jqjester
I'd rather have two simple things than one complex thing.

In the codebases I've worked on, a lot of the complexity I see arose from
people changing the meaning of existing code so they could 'reuse' it.

------
ape4
Writing software is all about managing complexity.

------
pjungwir
HN had another article a couple weeks ago asserting you shouldn't add business
processes to your company unless they had an expected value of increasing foo
by at least 10%. The author argued this was a good way of avoiding creeping
bureaucracy. It's striking how similar that is to this article's thesis re
code complexity.

------
orblivion
_Complexity is also introduced by well-meaning people on the implementation
side as well. Software developers like challenges, and the challenge of
building a complex system that serves up a simple interface is especially
alluring. Consider DSLs, abstractions and the attraction to being the one to
build a framework that gets leveraged for years. This drives us to introduce
huge complexity debt we defend with statements like "it makes it so easy once
you understand" and "it will save us so much coding." Writing the lines of
code is rarely the big cost in engineering: it's the understanding, the
communication and the maintenance._

Ok, but did it save so much coding, or not? I do try to restrain myself from
being clever when I realize it's really not worth it, but being clever
sometimes does pay off. Extra coding is complexity too.

~~~
orblivion
That said, making a _simple_ system that provides a simple interface to a
complicated (or at least, a sophisticated) issue, is much better. And, you
don't have to control your ego either. You can learn to take pride in the
expressiveness and simplicity of your code.

------
mikeschinkel
I've frequently heard designers, developers and VPs of Engineering -- which
I'll collectively call "builders" \-- argue that a product should have fewer
features and thus should be "simple."

But I honestly can't remember reading once when a _user_ has said they want
fewer features. Users want it to _easy_ , yes, but they also want the features
that make their lives, well, easier; see how that works?

Whenever I hear builders argue for simplicity I get deja-vu as if I'm hearing
union members argue against those who might cross the picket line, or
lobbyists trying to convince congress to give their clients tax breaks, or
record companies complaining about downloaded musics, or, or, or,... well you
get the picture.

~~~
roryokane
I think fewer features isn’t something a user would request. Fewer features is
just something they would notice the absense of. Users don’t always know what
they want.

For example, there may be a ten-item menu where the user only uses the two
features at the bottom. The user is slightly annoyed every time they have to
move the mouse all the way down there to select that feature. But it probably
wouldn’t occur to them to ask that the other menu items be removed – they are
just trying to ignore those items.

------
endgame
Is it poor submission titles?

Is it websites that pop up a subscription box with no obvious close button?

~~~
rschmitty
Title should be: The one "feature" that will cause users to practically insta-
close your website and not read the article.

------
mathattack
A lot of this is heading off complexity at the beginning. Every new feature
should come with "Do we really understand why we're doing this?" It's ok to
experiment, but prune prune prune....

------
sybhn
As an engineering manager I have struggled many times trying to convey the
real cost of these 'cant you just do this...' type of things. This article
makes a clear case in a structured way.

I haven't run into many product manager that would understand the cost
management exposed here. Most product development company I have been at avoid
discussion/debates around the real cost of some of the development.

I'm not sure whether it's the lack of understanding, or simply the lack of
interest for long term impacts sometime outlived by exit strategies.

------
w_t_payne
Brilliant article.

I have made similar observations in the past as well:

[http://williamtpayne.blogspot.co.uk/2012/05/complexity-it-
ha...](http://williamtpayne.blogspot.co.uk/2012/05/complexity-it-had-better-
be-worth-it_03.html)

As well the mistakes we tend to make when we try to deal with it:

[http://williamtpayne.blogspot.co.uk/2012/06/pushing-
complexi...](http://williamtpayne.blogspot.co.uk/2012/06/pushing-
complexity.html)

------
chmike
How do you know when you're making it too complex? On one hand you have Hello
world! And on the other the vilain project manager requests.

But say you design a distributed system and its protocol, how do you know what
is to keep and what is to delete ? We know the problem of over quality or
complexity, but how do you know you're just right?

My feeling is that beeing too minimalist might refrain progress and discovery
of new loved features.

------
gdilla
like a commenter suggests on the original post, end users don't care how
something is built, but how well it solves a problem of theirs. It's like
drucker saying costs have nothing to do with price. So, you can build things
with bloat but it'll put you out of business. You also have to do right by
your users. Not doing stuff because it's hard isn't a good excuse (a lot of
the time).

------
arscan
In short: KISS (Keep it Simple, Stupid)

That's one of my favorite principles of software development (and engineering
in general).

------
peterwwillis
Maintenance is 200% of the cost of writing software.

The first 100% of the cost is 20% writing, testing and certifying it, and 80%
maintaining the result.

The additional 100% is the cost of rewriting it because you didn't actually
write it to be maintainable.

------
CPAhem
Features are what sells products, the cost is that they make the product more
complex (and add to the cost).

Simple products are often easy to use, and document, which is one of the
reasons Apple does so well.

~~~
neilkelty
Solving problems sells software - features are just one way of getting there.

------
realrocker
To be clear, the author is talking about simplicity which comes out of years
of dealing with complexities. The better I get at engineering the simpler are
my solutions.

------
gopher1
I loved the article, and I like how the author implores us to extend the drive
to reduce complexity to how we speak about products.

------
lucdurette
Could not agree more. Very good paper!

------
benigeri
really good read

------
vacri
_Users don 't want complexity, either._

This is not true. Users want a manageable and _appropriate_ amount of
complexity. Sane defaults, reasonable options.

In the sitcom 'Allo 'Allo, a woman is trying to set up a date with a character
who's a stickler: "What if I am late?" > "Don't be late" > "What if I am
early?" > "Don't be early. Be _punctual_."

I'm reminded of this whenever I see something on the minimalist vs flexibility
wars. The answer is in neither camp, it's in the 'be appropriate' camp.

~~~
mikeschinkel
> Users want a manageable and appropriate amount of complexity. Sane defaults,
> reasonable options.

+1

------
leishulang
without reading the article, I guess it's communication.

~~~
mey
it's system complexity and how that makes it hard to maintain, change or
validate.

