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...?"
One cost engineers and product managers don't consider
11–20 of 102 posts
Re: One cost engineers and product managers don't consider
#12As 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.
Re: One cost engineers and product managers don't consider
#13The 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?
Re: One cost engineers and product managers don't consider
#14A 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....
Re: One cost engineers and product managers don't consider
#15For 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.
Re: One cost engineers and product managers don't consider
#16In my experience, practically everyone agrees that software should be simple, but not everyone agrees on what simple is.
Re: One cost engineers and product managers don't consider
#17The 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…
>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.
Re: One cost engineers and product managers don't consider
#18Whammed in the face with: "Subscribe to receive future articles right to your inbox" Tab closed. To hell with them.
Agreed!
Re: One cost engineers and product managers don't consider
#19The 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…
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.
Re: One cost engineers and product managers don't consider
#20The 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…
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?