Project partners, or, think like a consultant
by Andy Lester
Here's a little gem from
Matt Heusser, who's putting together tomorrow's
Perl Mongers meeting in Grand Rapids.
The attitude of "Just give me the requirements" fails because it has the customer solving the problem; the software developer becomes just a glorified technical writer that knows how to write in the language of a machine.
That doesn't diminish the importance of that coding skill. It's tough to write good, solid code, or else we wouldn't need jobs. What we help provide is the translation between the business needs and the capabilities of the computer.
The other problem with "Just give me the requirements" is that it's an attempt on the programmer's part to absolve himself from the responsibility of the project's success. If the requirements are handed to the programmer, created in a vacuum, the programmer has a ready scapegoat when the project fails. (And that probably is a "when", not an "if.")
Matt's original article is aimed at independent consultants, not those of us who are part of an IT department, but I suggest that we should all think of ourselves as consultants. When that happens, the "plan for having a scapegoat when the project fails" attitude will disappear. No consultant who wanted to make the mortgage would say "Just give me the requirements," and neither should those of us in IT.
Glorified technical writer ?
"... just a glorified technical writer that knows how to write in the language of a machine. "
Glorified Software Developers?
The two skill sets are pretty diverse. There are quite a few programmers whose prose you don't want to read. (I can think of a couple of book publishers who've done pretty well selling things that might otherwise have been manuals.) There are plenty of technically-minded writers who couldn't code their way out of "Hello, world!\n".