Live data from Hacker News

One cost engineers and product managers don't consider

firstround.com

41–50 of 102 posts

Re: One cost engineers and product managers don't consider

#41
post #13

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…

I think that first comment completely misses the point of the article. It's not a matter of whether or not you should or shouldn't make things simpler for the user. It's that you shouldn't view changes as one-time costs - you need to take into account the lifetime maintenance cost of that change you will have to live with. Many times, it is worth the cost because it solves the end-user's problem, that's true. But the point is that we often don't even consider it.

Re: One cost engineers and product managers don't consider

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

Re: One cost engineers and product managers don't consider

#43

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 statement…

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.

Re: One cost engineers and product managers don't consider

#44
(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

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

Re: One cost engineers and product managers don't consider

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

Re: One cost engineers and product managers don't consider

#46
post #4

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 Gn…

That's how I feel about Apple deeming unimportant my Home, End, PgUp, PgDn, and front-delete keys.

Re: One cost engineers and product managers don't consider

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

Re: One cost engineers and product managers don't consider

#48
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?

Re: One cost engineers and product managers don't consider

#49
post #15

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…

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

Re: One cost engineers and product managers don't consider

#50
post #4

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 Gn…

That's how I feel about Apple deeming unimportant my Home, End, PgUp, PgDn, and front-delete keys.

RIGHT ON, BROTHER!
Post reply on HN