Introduction
When I was a young man (yes that’s been a while now) I suffered from Y.E.D. (Young Engineer’s Disease). Here are some of the symptoms.
Sunny-Day Design
The design assumes the user thinks like a software engineer. For example, the user is expected to:
- Click buttons in a prescribed order.
- Know, or be able to deduce, things that will and will not work.
- Comprehend technical jargon.
The problems with these assumptions are obvious: Users click what they want when they want and they will eventually try every permutation of button clicks; they cannot always deduce what will and will not work; and they do not always comprehend technical jargon.
The solution is to hide or disable buttons you do not want pushed; provide in-line feedback, help, and status messages; and spell out exactly what the application will do and when it will do it. Equally important (if not more so) is to explain what the application will not do. It’s not that users are dumb. It’s not their job to interpret what we meant when we developed the application. It’s our job to develop intuitive applications.
One Size Fits All
Young Engineers rarely consider scale. Scale requires multi-dimensional thinking and that’s hard.
Often, folks develop software to solve a particular problem. There’s nothing wrong with that. The issue begins when the problem solved is not that big a deal in the original enterprise, but is a huge problem in for a different company, or relatively the same size in a much larger corporation. I’ve seen many an application delivered to a large enterprise only to fall on its face as soon as it’s under load. Bummer.
The solution is to think in those other dimensions. Don’t merely imagine what would happen to your application if it was pushed beyond the envelope, push it until it breaks and find out!
Grand Unified Solution
Sometimes Young Engineers write “Silver Bullet Applications”. More often, Young Engineers think they’ve written a silver bullet application.
Silver bullets are hard. Making software that’s really good at one thing is difficult enough. Refactoring the same software to solve an issue that appears similar is often more work than imagined. In my experience, it’s usually a lot harder than anyone expects at the start. Why try to refactor then? Young Engineers readily identify the 90% of functionality overlap between the requirements. They fail to recognize the remaining 10% will not translate into “1/9th of the time it took to write the 90%”. It usually takes much longer. And the increased complexity of bending an application to perform a more rich set of operations easily adds an order of magnitude to the complexity of the necessary coding.
The solution is really twofold: Either architect solutions from the beginning with multiple solutions in mind, resist the urge to refactor an existing application into a Grand Unified Solution, or both.
Conclusion
My bride Christy has an excellent saying: “Good judgment comes from experience, and experience comes from bad judgment.” Y.E.D. is a self-correcting problem.
Young Engineers are tomorrow’s architects. One of the most important jobs for today’s architects is mentoring them.
:{>
It is nice to see this summarized so nicely. It will make a great reminder of mistakes to avoid. I already make many of these mistakes much less frequently than a year ago, but still more frequently than I am comfortable with, so the reminder will be very handy.
Hi Mike,
If you don’t look at code you wrote six months ago and cringe, you’re not growing.
:{>
That is very encouraging. Almost every bit of code I wrote 6 months ago makes me cringe. Granted, the bits that don’t make me cringe tend to be the parts like DECLARE statements.
I’d like to print that (“If you don’t look at code you wrote six months ago and cringe, you’re not growing.”) in banner form for my desk, or make one of those motivational pictures (someone doing a facepalm maybe?) out of it.
There’s some code I wrote that’s stood the test of time (requirements haven’t changed, and the code still performs the intended function well), some I cringe at because I know of better ways now (sometimes due to new version functionality) but haven’t had a chance to implement, and some I still cringe at thinking there still has to be a better way and still searching for it.
Great post, Andy! I can’t tell you how many times I have seen symptoms of Sunny-Day Design! Especially the "click buttons in a prescribed order". The parallel to that is "enter data in the fields in a prescribed order" too. How many times have you seen someone trapped in an infinite loop because they entered wrong dates and the validation routine keeps kicking them out of the place where they need to fix it, telling them that they have invalid dates.
I 100% believe in Christy’s quote, but as much as possible, I try to gain good judgment from learning from OTHER peoples’ experience and bad judgments. It’s less painful that way. But believe me, I have plenty of my own scars that I have picked up along the way.