Thomas the Tank Engine on Software Requirements
At my house, we recently entered the phase of fascination with Thomas the Tank Engine. If you're not familiar with Thomas and his many, many, many friends on the Island of Sodor, then you must not know anyone between the ages of 2 and 10, because they're a hit with that crowd. In fact, my son has decided that he'd rather "watch Thomas videos?" (said in his cute little "please" voice the first time) ... "watch Thomas videos" (said a bit more directly the next time) ... "WATCH THOMAS VIDEOS!!!" (you get the picture) than do just about anything else. So, I now am learning a lot about Thomas and his friends.
One of the most important things on the Island of Sodor is to be "really useful." The engines spend a lot of time worrying about whether or not they're being useful and trying to find new ways to be more useful. The highest praise a tank engine can receive is for Sir Topham Hatt (who runs the place) to tell the engine how useful he or she has been.
Being Helpful Isn't Enough
I've spent more time than I'd like to admit wondering why being useful is the most important thing on Sodor. Why not being helpful? Or being friendly? Or sharing? Or eating your vegetables? Or any of the other lessons that kids need reinforced? Is rail baron Hatt on to something?
When I put the question in terms of requirements work, it makes much more sense to me (which probably says something about the odd way I think). When working on a requirements project, it's great to be helpful and friendly and share (eating your veggies is a good idea, too, but of less importance in this case). However, all of those qualities may not actually help you do the job a requirements engineer is supposed to do.
Provide Useful Software Requirements Work
If I'm helpful in supporting existing processes which enable the project to fail, that's no good. If I'm friendly but let the stakeholders change requirements willy-nilly, that's no good either. And if I share the requirements information with the development team but they can't understand it, then what good have I done?
What's more important is that I do things which are useful to the project. I suggest (dare I say "implement"?) process changes which will help the project succeed. I force the business to make hard decisions about scope. I work with the dev team to make sure that the requirements are understood. And in doing so, I am "really useful indeed," as Sir Topham Hatt would say.
And then I eat my lima beans.
One of the most important things on the Island of Sodor is to be "really useful." The engines spend a lot of time worrying about whether or not they're being useful and trying to find new ways to be more useful. The highest praise a tank engine can receive is for Sir Topham Hatt (who runs the place) to tell the engine how useful he or she has been.
Being Helpful Isn't Enough
I've spent more time than I'd like to admit wondering why being useful is the most important thing on Sodor. Why not being helpful? Or being friendly? Or sharing? Or eating your vegetables? Or any of the other lessons that kids need reinforced? Is rail baron Hatt on to something?
When I put the question in terms of requirements work, it makes much more sense to me (which probably says something about the odd way I think). When working on a requirements project, it's great to be helpful and friendly and share (eating your veggies is a good idea, too, but of less importance in this case). However, all of those qualities may not actually help you do the job a requirements engineer is supposed to do.
Provide Useful Software Requirements Work
If I'm helpful in supporting existing processes which enable the project to fail, that's no good. If I'm friendly but let the stakeholders change requirements willy-nilly, that's no good either. And if I share the requirements information with the development team but they can't understand it, then what good have I done?
What's more important is that I do things which are useful to the project. I suggest (dare I say "implement"?) process changes which will help the project succeed. I force the business to make hard decisions about scope. I work with the dev team to make sure that the requirements are understood. And in doing so, I am "really useful indeed," as Sir Topham Hatt would say.
And then I eat my lima beans.
Labels: business analyst, software requirements
posted by Mike Alexander at 6/12/2008 08:23:00 AM
2 Comments:
Hey Mike. I love your posts that include lessns from your kids lives.
TTTE's not so subtle moral backstory seems to me to be about the industrial revoluiotn of the 19th century where a lot of not so useful (adaptable) people were displaced by new technology.
Is there another story in that?
Thanks, Craig! Glad to know that folks are enjoying the posts!
I'm sure there's an element of that lesson in TTTE. If I have my timing right, the books started coming out right after WWII, so I'd wager that there's an element of "support the troops" in there, too.
In any case, I'm certain that there are more stories for our profession in children's television. Maybe I'll tackle Sesame Street next!
Post a Comment
<< Home