10 ms·

One cost engineers and product managers don't consider

296 points by jkopelman 13y ago

leishulang 13y ago
without reading the article, I guess it's communication.
- mey 13y ago
  it's system complexity and how that makes it hard to maintain, change or validate.
RyanZAG 13y ago
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.
- noir_lord 13y ago
  You could also drop a feature used by 1% who just happen to be the 1% who make the buying decisions or are vocal. I call these User Landmines (they are quiet right up until you step on one).
- notahacker 13y ago
  On a similar note, this bit caught my eye: It's often subtle or intentionally hidden features that cost the most in the long term. Yammer has long had a feature that allows you to begin a message with "to:" and a username to send a private message to someone, or followed by a group name to post to a group. This probably took me an hour to implement, test and deploy back in early 2008. I have easily spent 40 hours of my time -- and, necessarily, 40 hours of others' time -- over the intervening 5 years explaining this feature and its justification. One likely reason why an engineer - as opposed to a sales or customer support rep(1) - might end up spending as much as 40 hours explaining and justifying a trivial, implemented and documented feature would be a culture obsessed by removing perceived cruft. (1) If competent sales or customer support reps spend 40 hours talking about a feature then some conceivable variant of it has some perceived value to someone...
  - anigbrowl 13y ago
    I have to say that two man-weeks in 5 years for a feature with pretty high utility doesn't seem that much of a burden. However, I'm quibbling over words- I agree with the general thrust of his argument.
- acjohnson55 13y ago
  That's how I feel about Apple deeming unimportant my Home, End, PgUp, PgDn, and front-delete keys.
  - mikeschinkel 13y ago
    RIGHT ON, BROTHER!
  - roryokane 13y ago
    Just in case you’re not aware: the Fn key, in conjunction with the arrow keys or the delete key, let you type those keys. Though that’s certainly not as convenient as having dedicated keys. Also, you can remap different keys to those keys with the free software KeyRemap4MacBook (https://pqrs.org/macosx/keyremap4macbook/index.html.en https://pqrs.org/macosx/keyremap4macbook/index.html.en). For instance, you can remap \ to be forward-delete and Fn+\ to be typing ‘\’.
    - acjohnson55 13y ago
      That's fine and good, until you want to use key combinations that include the missing keys, particularly selection type stuff. For me, it comes up a lot in programming, writing, and file/photo management.
      - __david__ 13y ago
        I find that Shift-Fn is particularly easy to chord since they share a boundary. I usually use pinky on Fn and ring finger on Shift.
- RyJones 13y ago
  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.
  - gwilkes 13y ago
    Seriously doubt this has changed, even now Japan sells millions of fax machines a year domestically, Japan loves paper.
  - smartician 13y ago
    Problem is then that you have two cases that need to be tested and taken into consideration when designing etc.
- spullara 13y ago
  No one is using this password reset feature, lets drop it.
gdilla 13y ago
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).
ape4 13y ago
Writing software is all about managing complexity.
gopher1 13y ago
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.
arscan 13y ago
In short: KISS (Keep it Simple, Stupid) That's one of my favorite principles of software development (and engineering in general).
kryten 13y ago
Whammed in the face with: "Subscribe to receive future articles right to your inbox" Tab closed. To hell with them.
- eieio 13y ago
  I kept reading but definitely found it annoying. It also took a few seconds to load and the page scrolled back to the top, causing me to lose my place. Extra annoying.
- jerrya 13y ago
  Agreed!
- andrewcooke 13y ago
  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 13y ago
    I have adblock and ghostery. It still appeared for me. Perhaps I should use noscript as well :)
    - foobarian 13y ago
      I rarely see this stuff in w3m ;)
realrocker 13y ago
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.
Domenic_S 13y ago
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...?"
sybhn 13y ago
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.
emingo 13y ago
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?
- nijk 13y ago
  Look up "worse is better"
- coolsunglasses 13y ago
  >Does simplifying the front end often compromise the backend? Sometimes but not necessarily unless you're making a programming language or a platform. For typical, more direct cases it's not necessarily the case at all.
- doorty 13y ago
  In my experience, any interface that does not directly conform to the underlying technology is going to increase the amount of work (aka complexity). And typically, the reason why one interface is simpler than the other is because instead of conforming to the environment/language, the engineer had to code another way to do it.
- wisty 13y ago
  It depends on what stage this is done at. Imagine everything is linked to a user. How hard would it be to allow anonymous posts?
- betenoire 13y ago
  The two are not mutually exclusive, and solving both of those is what makes programming hard and fun.
- marcosdumay 13y ago
mathattack 13y ago
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....
nhashem 13y ago
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.
- nnq 13y ago
  > the business units are so disconnected from engineering they don't even realize the costs of what they're asking for In software you get this at all levels, including in the freelance/consulting world - people have no clue of the costs of what they're asking for so when they can't even make bad guesses, they go with "how hard would it be..." for a big feature request or "can't you just..." for what they see as a small one. I always prefer honesty over this - if you have no idea about even estimating the cost for some feature, just ask "How much will it take and how much will it cost to... ?", don't fuddle around with the "how hard...", "can't you..."... these are just weasel words for when you need to overwork and underpay someone because you really know you need something done yesterday and with almost no budget, but you really need it so maybe someone will just shoot himself in the foot to make it work for you if you ask nicely enough :)
DanWaterworth 13y ago
In my experience, practically everyone agrees that software should be simple, but not everyone agrees on what simple is.
- obviouslygreen 13y ago
  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 13y ago
    Perhaps the reason I haven't shared your experience is because I primarily deal only with tech people.
- thezilch 13y ago
  As another child comment identifies, we should not confuse simple with easy. Clients want easy software, and they have little care or understanding of the complexity. That's OK, on its head, but it is our responsibility to share and teach this side of the software's lifecycle with "management" and "junior" developers. Rich Hickey, author of Clojure, had a great talk on simplicity and easiness of software [0]. [0] http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
- michaelfeathers 13y ago
  Simple is good, but the thing you really want is orthogonality - the ability to change one thing without affecting another. Generally, you get that by moving toward small, focused abstractions.
benigeri 13y ago
really good read
peterwwillis 13y ago
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.
russelluresti 13y ago
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 13y ago
  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".
  - frenchy 13y ago
    In my experience, this is usually the project managers. The engineers would love to remove the unused cruft, but the project managers don't see it as beneficial and always make other priorities.
  - russelluresti 13y ago
    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 13y ago
vacri 13y ago
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 13y ago
  > Users want a manageable and appropriate amount of complexity. Sane defaults, reasonable options. +1
orblivion 13y ago
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 13y ago
  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.
kfcm 13y ago
(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.
pjungwir 13y ago
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.
ChuckMcM 13y ago
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 13y ago
  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.
pedalpete 13y ago
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?
- krakensden 13y ago
  if you aren't allowed to spend more than 1-2 days writing and testing any particular unit of work, agglomeration is the dominant strategy.
- jqjester 13y ago
  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.
mikeschinkel 13y ago
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 13y ago
  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.
- LordHumungous 13y ago
  What users say they want and what they will actually use are often completely different.
itsybitsycoder 13y ago
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.
CPAhem 13y ago
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 13y ago
  Solving problems sells software - features are just one way of getting there.
chmike 13y ago
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.
michaelfeathers 13y ago
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-keynote-code-blindness http://www.confreaks.com/videos/717-rockymtnruby2011-opening... http://michaelfeathers.typepad.com/michael_feathers_blog/2011/05/the-carrying-cost-of-code-taking-lean-seriously.html http://michaelfeathers.typepad.com/michael_feathers_blog/201...
endgame 13y ago
Is it poor submission titles? Is it websites that pop up a subscription box with no obvious close button?
- rschmitty 13y ago
  Title should be: The one "feature" that will cause users to practically insta-close your website and not read the article.
w_t_payne 13y ago
Brilliant article. I have made similar observations in the past as well: http://williamtpayne.blogspot.co.uk/2012/05/complexity-it-had-better-be-worth-it_03.html http://williamtpayne.blogspot.co.uk/2012/05/complexity-it-ha... As well the mistakes we tend to make when we try to deal with it: http://williamtpayne.blogspot.co.uk/2012/06/pushing-complexity.html http://williamtpayne.blogspot.co.uk/2012/06/pushing-complexi...
deleted 13y ago
[deleted]
lucdurette 13y ago
Could not agree more. Very good paper!

296 points by jkopelman 13y ago

leishulang 13y ago

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

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

RyanZAG 13y ago

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.

noir_lord 13y ago
You could also drop a feature used by 1% who just happen to be the 1% who make the buying decisions or are vocal. I call these User Landmines (they are quiet right up until you step on one).
notahacker 13y ago
On a similar note, this bit caught my eye: It's often subtle or intentionally hidden features that cost the most in the long term. Yammer has long had a feature that allows you to begin a message with "to:" and a username to send a private message to someone, or followed by a group name to post to a group. This probably took me an hour to implement, test and deploy back in early 2008. I have easily spent 40 hours of my time -- and, necessarily, 40 hours of others' time -- over the intervening 5 years explaining this feature and its justification. One likely reason why an engineer - as opposed to a sales or customer support rep(1) - might end up spending as much as 40 hours explaining and justifying a trivial, implemented and documented feature would be a culture obsessed by removing perceived cruft. (1) If competent sales or customer support reps spend 40 hours talking about a feature then some conceivable variant of it has some perceived value to someone...
- anigbrowl 13y ago
  I have to say that two man-weeks in 5 years for a feature with pretty high utility doesn't seem that much of a burden. However, I'm quibbling over words- I agree with the general thrust of his argument.
acjohnson55 13y ago
That's how I feel about Apple deeming unimportant my Home, End, PgUp, PgDn, and front-delete keys.
- mikeschinkel 13y ago
  RIGHT ON, BROTHER!
- roryokane 13y ago
  Just in case you’re not aware: the Fn key, in conjunction with the arrow keys or the delete key, let you type those keys. Though that’s certainly not as convenient as having dedicated keys. Also, you can remap different keys to those keys with the free software KeyRemap4MacBook (https://pqrs.org/macosx/keyremap4macbook/index.html.en https://pqrs.org/macosx/keyremap4macbook/index.html.en). For instance, you can remap \ to be forward-delete and Fn+\ to be typing ‘\’.
  - acjohnson55 13y ago
    That's fine and good, until you want to use key combinations that include the missing keys, particularly selection type stuff. For me, it comes up a lot in programming, writing, and file/photo management.
    - __david__ 13y ago
      I find that Shift-Fn is particularly easy to chord since they share a boundary. I usually use pinky on Fn and ring finger on Shift.
RyJones 13y ago
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.
- gwilkes 13y ago
  Seriously doubt this has changed, even now Japan sells millions of fax machines a year domestically, Japan loves paper.
- smartician 13y ago
  Problem is then that you have two cases that need to be tested and taken into consideration when designing etc.
spullara 13y ago
No one is using this password reset feature, lets drop it.

gdilla 13y ago

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

ape4 13y ago

Writing software is all about managing complexity.

gopher1 13y ago

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.

arscan 13y ago

In short: KISS (Keep it Simple, Stupid) That's one of my favorite principles of software development (and engineering in general).

kryten 13y ago

Whammed in the face with: "Subscribe to receive future articles right to your inbox" Tab closed. To hell with them.

eieio 13y ago
I kept reading but definitely found it annoying. It also took a few seconds to load and the page scrolled back to the top, causing me to lose my place. Extra annoying.
jerrya 13y ago
Agreed!
andrewcooke 13y ago
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 13y ago
  I have adblock and ghostery. It still appeared for me. Perhaps I should use noscript as well :)
  - foobarian 13y ago
    I rarely see this stuff in w3m ;)

realrocker 13y ago

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.

Domenic_S 13y ago

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

sybhn 13y ago

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.

emingo 13y ago

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?

nijk 13y ago
Look up "worse is better"
coolsunglasses 13y ago
>Does simplifying the front end often compromise the backend? Sometimes but not necessarily unless you're making a programming language or a platform. For typical, more direct cases it's not necessarily the case at all.
doorty 13y ago
In my experience, any interface that does not directly conform to the underlying technology is going to increase the amount of work (aka complexity). And typically, the reason why one interface is simpler than the other is because instead of conforming to the environment/language, the engineer had to code another way to do it.
wisty 13y ago
It depends on what stage this is done at. Imagine everything is linked to a user. How hard would it be to allow anonymous posts?
betenoire 13y ago
The two are not mutually exclusive, and solving both of those is what makes programming hard and fun.
marcosdumay 13y ago

mathattack 13y ago

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

nhashem 13y ago

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.

nnq 13y ago
> the business units are so disconnected from engineering they don't even realize the costs of what they're asking for In software you get this at all levels, including in the freelance/consulting world - people have no clue of the costs of what they're asking for so when they can't even make bad guesses, they go with "how hard would it be..." for a big feature request or "can't you just..." for what they see as a small one. I always prefer honesty over this - if you have no idea about even estimating the cost for some feature, just ask "How much will it take and how much will it cost to... ?", don't fuddle around with the "how hard...", "can't you..."... these are just weasel words for when you need to overwork and underpay someone because you really know you need something done yesterday and with almost no budget, but you really need it so maybe someone will just shoot himself in the foot to make it work for you if you ask nicely enough :)

DanWaterworth 13y ago

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

obviouslygreen 13y ago
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 13y ago
  Perhaps the reason I haven't shared your experience is because I primarily deal only with tech people.
thezilch 13y ago
As another child comment identifies, we should not confuse simple with easy. Clients want easy software, and they have little care or understanding of the complexity. That's OK, on its head, but it is our responsibility to share and teach this side of the software's lifecycle with "management" and "junior" developers. Rich Hickey, author of Clojure, had a great talk on simplicity and easiness of software [0]. [0] http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
michaelfeathers 13y ago
Simple is good, but the thing you really want is orthogonality - the ability to change one thing without affecting another. Generally, you get that by moving toward small, focused abstractions.

benigeri 13y ago

really good read

peterwwillis 13y ago

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.

russelluresti 13y ago

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 13y ago
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".
- frenchy 13y ago
  In my experience, this is usually the project managers. The engineers would love to remove the unused cruft, but the project managers don't see it as beneficial and always make other priorities.
- russelluresti 13y ago
  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 13y ago

vacri 13y ago

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 13y ago
> Users want a manageable and appropriate amount of complexity. Sane defaults, reasonable options. +1

orblivion 13y ago

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 13y ago
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.

kfcm 13y ago

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

pjungwir 13y ago

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.

ChuckMcM 13y ago

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 13y ago
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.

pedalpete 13y ago

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?

krakensden 13y ago
if you aren't allowed to spend more than 1-2 days writing and testing any particular unit of work, agglomeration is the dominant strategy.
jqjester 13y ago
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.

mikeschinkel 13y ago

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 13y ago
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.
LordHumungous 13y ago
What users say they want and what they will actually use are often completely different.

itsybitsycoder 13y ago

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.

CPAhem 13y ago

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 13y ago
Solving problems sells software - features are just one way of getting there.

chmike 13y ago

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.

michaelfeathers 13y ago

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-keynote-code-blindness http://www.confreaks.com/videos/717-rockymtnruby2011-opening... http://michaelfeathers.typepad.com/michael_feathers_blog/2011/05/the-carrying-cost-of-code-taking-lean-seriously.html http://michaelfeathers.typepad.com/michael_feathers_blog/201...

endgame 13y ago

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

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

w_t_payne 13y ago

Brilliant article. I have made similar observations in the past as well: http://williamtpayne.blogspot.co.uk/2012/05/complexity-it-had-better-be-worth-it_03.html http://williamtpayne.blogspot.co.uk/2012/05/complexity-it-ha... As well the mistakes we tend to make when we try to deal with it: http://williamtpayne.blogspot.co.uk/2012/06/pushing-complexity.html http://williamtpayne.blogspot.co.uk/2012/06/pushing-complexi...

deleted 13y ago

[deleted]

lucdurette 13y ago

Could not agree more. Very good paper!