The Business of Programming

Tuesday, July 15, 2014

I recently spoke to a businessman about his project. He'd handed it off to a couple of programming teams and the result was the same each time.

Failure.

Every software engineer wants to be the one who can do what another guy can't, so I asked to so see the writeup describing his project.

I was shocked. Maybe that wasn't it. I was bemused. I didn't know whether to laugh or tell him to lawyer up.

It was obvious why each and every team had failed. The person who had generated the requirements had no idea what he was doing. I saw pages and pages of contradictions, ambiguities and useless requirements that did nothing but add unneeded complexity to the job.

The root cause of his troubles was obvious. The world is full of hacks who pick up a copy of "Learn Java in 21 days" and think they are somehow qualified to write software for businesses.

It doesn't work that way! It's like buying a book on penmanship and assuming that you'll magically become a great poet.

Software engineering teams need to be able to break down business problems into manageable parts that make sense. They need to communicate requirements in a way that can be understood. In short, they need to stop focusing on buzzwords and start focusing on providing real value to real businesses.

It's no surprise that most programmers don't care about providing real value. Most hiring managers and businesses don't either. One only has to look at job ads to see the "must have used XYZ technology for 5-10 years" mindset. It's dangerous and leads to people learning buzzwords rather than practical skills that lead to successful projects.

Programmers everywhere - please put down the latest buzzword compliant book and start figuring out how to solve business problems. Know what a Gantt chart is. Take a class in managerial economics. Figure out how to speak with a nontechnical person and find out what his problems are.

In the meantime, we're open for business... and we get business!