Seiter's Blog

It was about 50 degrees outside and breezy in Half Moon Bay, California when I overheard three people discussing robots over lunch.

"So we'll buy the robot for about 50k, then we'll need about 20k more for setup and configuration. That covers pretty much everything except software, which will cost infinity."

They all laughed and one of them, who looked like the guy who paid the bills, rolled his eyes and nodded as if this joke weren't all that far from the truth.

And of course, it isn't. I've written about software for many years now with varying degrees of accuracy. As I've gotten older and experienced more projects, it has become entirely evident that software has a lot of big problems. There are many paradigms out there which promise all kinds of benefits, some of which can be realized. Unfortunately at the end of the day, complex systems are complex. And while that doesn't sound like much, it's altogether meaningful when architects around the world fall prey to silver bullet solutions, shortcuts and other methodologies that often cause more harm than good or lead customers to unreasonable expectations about results.

So what are we to do about this? How can we bring "infinity" to something more reasonable? Here are my suggestions, which are the product of experience and of nothing else.

1. Complex systems are complex: The first mistake any architect can make is to assume he/she fully understands any complex system. I'm not talking about Hello World, or your senior project. I'm talking about multi-component systems. I'm talking about moving parts and integrated systems. Many architects will go up to a white board and draw a bunch of boxes which correspond to subsystems. Since they can see all of the boxes, they assume they understand the system as a whole. I walk up to the board and say, "Draw the lines." Please draw the lines between systems and while you're at it, explain how every line works. And while you're at that, tell me what happens to the system when a line doesn't work as expected. Tell me what happens when 75% through the project, someone draws a new line. Great architects not only recognize that they don't fully understand the complex system, they embrace it. And in this way, they learn to prepare for the unknown.

2. Hire great engineers: Time after time, this is the moral of the story. Again and again, this single factor can determine the success or failure of major components of a system. A good engineer is not one with an incredibly lengthy title. A good engineer is not the hot-off-the-press graduate and it's not the guy with 15 years of experience. A great engineer only concerns himself with the task of solving problems and if he/she has any of the above as well, fantastic. When you interview your potential engineers, ask them to describe something they are proud about having done. "Completed XYZ project" and "Met XYZ deadline" are fine answers but they aren't great answers. "I figured out how to integrate a 15 year old cold-fusion app with a modern web-service using SOAP and a few hundred lines of code I wrote." Bingo.

3. Don't blame your customer: Isn't it easy to blame the customer? A couple useless words fly out of your mouth and you feel better about the fact that you're changing something about your system yet again. Unfortunately, this does nothing to help solve the problem. Customer problems are complex and it would take me ten pages to talk about them in their entirety. I'm also completely unqualified to do so. What I can say is that I've seen this mentality in many organizations and in many engineers. I've seen it in project managers and I've seen it in myself. The truth is, this mentality does nothing to help you accomplish your goal. There are entire books devoted to managing customer expectations and project managers tend to be better at this than engineers do. The best thing you can do as an engineer is to take changes in stride and try to engineer your software to be flexible. Requirements are driven by customers and customers are human. Accept this fact and you'll find yourself in a much happier, healthier engineering state. And your customer will notice.

Related: To Engineer or Not to Engineer