Software Companies and Discipline

Anderson brings up to my next point - what would you consider discipline in a software company?

The first discipline concept is Disciplined People. Most top-notch software shops know how to hire disciplined employees - individuals who never stop learning, and who are committed to building (and shipping) great software. You want everyone on board to be serious about their craft (whether it is a developer, tester, or manager). They need to have both the guts and the ability to take your company to Great (as capitalized by Jim Collins).

The next concept is Disciplined Thought. You've hired the right people. They have the raw abilities, and they have the gumption to perform at their best. Now, comes the unified part. You have to harness all of that discipline and focus it on your software. This is hard. You need to create a sense of unity. It's not the testers vs. the developers. It's not management vs. everyone else. The entire team needs to be "signed up" to deliver Great software. Again - if you've got Disciplined People, this part should be cake.

Finally, there's Disciplined Action. This is definitely the hardest part to "get right." It's crucial that the first two ideas happen before this one can be truly successful. I myself have a hard time with it - undisciplined thoughts that turn into actions can make it look like it's a failure in execution, rather than planning. (Especially when you have several successes under your belt.)

Developers are notorious for being bleeding-edge adopters. It's practically a badge of honor to be running nothing but beta software on one's machine. I'm no exception - it's happened in the past, and right now I've got two different versions of Visual Studio running side-by-side. What happens is if you let this tendency run wild in your software, you will have problems. I'm not saying new technology is a bad thing. I can't wait to replace some of my Dictionaries with HashSets. LINQ is undoubtedly cool. And don't get me started on lamdas. But, there's no way I would try to integrate .NET 3.5 into an existing project that needs to ship anytime soon. I've been down that road before, and I know where it ends. (Hint: it's a particularly "deathly" kind of "march.")

You get the right people, who will make the right decisions, and execute them properly. For a software company, this means hiring people who will ship great software, and base their decisions and actions around that concept. Developers write high quality, unit tested code. Testers make sure the code meets requirements and is of high quality. Managers keep the machine running smoothly, and block any attempts to foul it up. Business analysts figure out what the customer really wants. And no one makes decisions that will run contrary to the desired outcome - shipping Great software.