Baby, walk the walk

responded quickly to my little nudgeback earlier. And she’s sticking by her guns: But, dang it, this time I am not wrong.

Good on you, Dorothea. I like people who stand their ground. I rarely do so it’s very refreshing for me to see it in others. However, I have to respectfully disagree with your assessment that software can only be created by people who’ve done the work – walked the walk, so to speak. In some ways…, well, okay in some twisted ways, that’s the same as saying I can’t really understand what happens in the massage parlor business just from the explicit requirements given me by the Madame.

Good, well trained programmer/analysts are expert in interviewing clients and putting their words into requirements that other developers can follow. After you work in an industry for a while you pick up the talk, as I have with manufacturing; but you never need to actually do the work to get this understanding. It’s a question of meeting with the folks who are expert and knowing how to maximize their time. The key really is respect.

As for commercial software, at Sierra Geophysics, a petroleum industry software company, we would meet with engineers from the parent company, Halliburton, on a regular basis to check the requirements, and also to test out prototypes as well as review the manuals for completeness. We also had domain experts on site, which isn’t unusual for specialized software companies such as ours; but most of the requirements came from working directly with the clients.

When I worked at Skyfish, I also met with folks who ran airports and who manufactured planes to capture requirements from them. And our software was good because it was the only thing of value when the company crashed and burned.

If I had to walk the walk in each of these businesses in order to capture and document the requirements, as well as build the applications, I would be the first commercial pilot who knew how to drill oil wells, while working on an assembly line. (This in addition to being able to give a darn fine massage.)

Now, as Ralph mentioned in my comments, not all programmers can work with clients, or record requirements, and that’s cool, because not every programmer needs to. As long as everyone follows the spec, the application works.

The issue about having to be a domain expert in order to develop software just isn’t so. Not only that, it can be harmful to a company. A case in point: at one of the insurance company’s I worked with as a consultant, a group of insurance people who came over to the dark side and became programmers tried to convince management that it was impossible to document their application – too complex said they. You’d have to be a domain expert to understand.

Now, it is true that some of the calculations in the insurance industry put NASA to shame. However, the manager wasn’t buying it and called me in. His concern, rightfully, is that this group was about to split off into a separate company, forcing the insurance company to have to ‘contract’ for the software. The manager was a bit peevish about this because the insurance company had paid to develop the software in the first place.

I met with the manager as well as the lead developer and listened to the latter’s spiel about how the calculations were too complex to document, only a domain expert could understand them. He emphasized this by waving around an actuarial manual that could have killed a small dog if it landed on it. How to Intimidate Programmers, 101 – wave around a really big manual.

When he was done, I told him that if he could document the calculations within a programming language well enough so the computer could understand him, he could document them enough in English so I could understand them, because if I wasn’t a domain expert, then neither was the computer.

Ralph also weighs in on this subject.

Print Friendly, PDF & Email