A Comfortable Couch

Wednesday, December 15, 2004

Good Engineering Takes Time

Sometimes being a really good engineer means seemingly simple things can a take a long time. Ned's post about whether he should use XML Schema to describe a relation schema I think is an example of this.

No doubt the relational schema is something that could have been described with imperative code, he could just throw lots of code at it and be done. But using imperative code sucks, its error prone, hard to read and hard to rearrange.

As an engineer who really wants more than anything to do it right, I often find that when faced with a problem I've never faced before I'll take a long time to produce small amounts of work. Some might say it's due to analysis paralysis, and sometimes it is. But usually it's more than that, it's about being real professional, it's about not producing crap, it's about taking pride in your work and seeing how good you can do it.

I want a solution that elegantly solves the problem, I want a solution that's easy to understand and maintain. And if at the very least I can't get something that's easy to understand, I want something that's hard to screw up in maintenance, so the next guy doesn't introduce bugs when doing simple things. I hate throwing lots of code at a problem, I want a solution that when another engineer looks at the code they might think "ahh very nice" or even not think about it all, they just grok it quickly and get their task done.

But its not just that I want the code to be better, it's also that I want me to be better. I want to know the best way (or least a really good way) to solve that problem the next time I face it. It adds another tool to my toolbox and makes me a more effective. It's happens occasionally that the time I'll spend on an elegant solution will simply not a have payoff for the problem at hand, but it has a payoff of making me a better engineer, of expanding my way of thing about a particular problem domain, of having the experience that I can share with others around me.

Good engineering practice means letting engineers spend the time to do their job as professionals, even if it means taking a little longer. Good engineering practice begets good code, bad engineering begets crap. It's pretty much unavoidable.

2 Comments:

Bob Balaban said...

I tend to agree with you, and I'm wondering what your reaction is to this post by Barry Briggs on SOA:
http://www.edithere.com/barry/2004/12/17#a1484

Is ROI the enemy of elegance?

8:43 AMlink  
Damien said...

Is ROI the enemy of elegance? I suppose if we could truly measure ROI, then no its not. But the ROI of any particular action and its ripple consequences is impossible to measure completely, especially the people issues.

For example, if a company lets an engineer spend an extra month refactoring a project, do they get that month investment back in some way? Well, if you don't let the engineer do it maybe he ends up leaving because he feels like he's never allowed to make the code into something he's proud of. In that case the extra cost necessary to find, train, and bring up speed his replacement is much much larger than that month spent making him happy. It's hard to make ROI measurements take those sorts of issues into account.

Regarding SOA, it makes sense to me on paper, but I don't think I'd go rewriting my systems just so I have SOA. But maybe other engineers would. If those engineers need to do it or they feel depressed and work more slowly on other things, maybe you should let them do it, measurable ROI be dammed.

Part of having a good engineering organization is letting engineers do the things that make them feel good about their work. Iris Associates was awesome in that regard, and it paid off quite nicely I think.

12:21 AMlink  

Post a Comment

<< Home