and Why Software Developers Need to Think About Them
It's recently occurred to me that materials are important. The things with which we work can influence not only the things that we produce, but also the way we think about the work itself.
Take the classic engineering example, building a bridge. Big bridges are harder to design and build than little ones. I built little bridges when I was a kid. I used popsicle sticks, twigs, mud, whatever. I probably built a bridge or two with my brother's erector set. Maybe used some TinkerToys. But that doesn't make me a Civil Engineer.
When I was a little bit older I went to Boy Scout camp and saw some pretty impressive rope bridges, more complicated and well-constructed than I could have made them. But that didn't make their makers Civil Engineers.
A Civil Engineer, or at least one who builds bridges, is expected to understand the proper use of materials to make a bridge that will hold the weight that it needs to hold, with a sound foundation, able to withstand adverse weather conditions, etc. I'm sure the list goes on and on, but I'm not a Civil Engineer. I think I mentioned that. I'm just a software guy who's musing about materials.
So the point, with respect to bridges, is simply this: no one would expect a kid--who knows how to nail a few boards to a couple fallen logs so he and his friends can cross a creek--to be able to construct something like the Golden Gate. Among all the other problems with that idea, it is obvious that the materials are different. One must learn how to use materials suitable for the task in order to build well.
Now for the software tie-in: we don't use materials. Or rather, our materials are all soft. There's no obvious distinction between the C++ that we write in our freshman programming class and the C++ that we use to build life-critical systems. It's all just code, right? Except it isn't. There's a huge difference between code acceptable for a classroom and code reliable enough to trust with human lives (usually OTHER humans' lives at that). That could be one reason why we don't understand why many developers who did well in school just don't know that their next project, the big project, is fundamentally different from anything else they've ever seen or done. And that could be one reason why management doesn't seem to understand that they can't just tell us when they want it, what it should do, how big the team will be, what tools we will use, and all the quality constraints within which we must operate. If a Civil Engineer says you can't build the Golden Gate with TinkerToys and ropes, people listen. But code is code, right?
We--software people--complain that we don't get the same professional respect that Engineers get. But then we deliver stuff that doesn't work, or doesn't work well enough, and it's late, and it cost too much, and we knew this would happen but we just went ahead with the project and let it happen. Real engineers don't do that. They have licenses to protect. They have reputations. They have standards. And they know the difference between play and work. We don't.
What's the answer? I don't know right now. Just musing. Had to get something down on electrons before the thought disappeared from my head. If you have some suggestions for how we can drive home to ourselves and our posterity the difference between toy code and real code, well, be sure to let me know.
--Erick
