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…
One cost engineers and product managers don't consider
41–50 of 102 posts
Re: One cost engineers and product managers don't consider
#42Ok, 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
#43Complexity 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…
Re: One cost engineers and product managers don't consider
#44--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
#45Re: One cost engineers and product managers don't consider
#46Good 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…
Re: One cost engineers and product managers don't consider
#47Google 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
#48I'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
#49For 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…
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
#50Good 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.