Comments on: The Danger of the Engineer who Can

By: Chris

Chris — Fri, 20 Mar 2009 08:02:45 +0000

Thanks David,
Yes, you’re right, and even push the complication all the way back on to the user.

By: Chris

Chris — Fri, 20 Mar 2009 08:01:21 +0000

Thanks Adam,
Yes; prioritisation of features based on ease of implementation and whim of engineer! Never mind all the baloney about user need and benefit, nor about ensuring that features fit together in a sensible way and are targeted towards product strategy. Just hack some cool stuff in! No, really, I’m being sarcastic.

By: Adam Bullied

Adam Bullied — Fri, 20 Mar 2009 02:33:06 +0000

Great post, Chris – and very true. Engineers are typically quite eager to prove their technical prowess – and in some cases, think they are serving the users better by simply “giving them what they want” and coding up a feature over the weekend they heard a user mention somewhere along the way.

The danger with this approach, even though it produces new technology rapidly, is that it only ever helps to create a jagged product. The road to hell is always paved with the best intentions; the logic of “a user asked, and I can easily code that, so we should give it to them” is faulty logic.

And while all of the components, modules, and features may be technically proficient or worth discussing at a conference with other engineers, they aren’t digestible by any sort of user, client, customer, or market.

By: David Locke

David Locke — Fri, 20 Mar 2009 02:22:48 +0000

I once asked an ASIC chip designer. “When would they put MS Word on a Chip?

“Never.”

When hardware gets hard, they turn it into software. If the technology is a mess, the system programmers leave it for the IT programmer. There is always another layer to leave it for. Surprise! That’s OK, it will be in your layer tomorrow. So it goes.

With some enterprise software, they even pushed the complication out into the business process.