Hackery vs. Mastery

Several years ago I had the pleasure of having lunch with Mark Shuttleworth, the CEO of Canonical which is the company that develops Ubuntu Linux. The conversation turned towards "Hackery vs. Mastery." Sometimes the forms of the word "hack" are positive and sometimes they are negative. When someone hacks your bank account and steals all of your money, it is a bad word. When you work to hack together a good solution to a complex problem, it is a positive word.

Our discussion put the word "hack" in a negative light as we discussed how sometimes people will hack together a solution instead of taking the time to do things correctly. A short while after our discussion, I had the chance to work with another group in our company that is famous for hacking together solutions. They prided themselves on building software quickly. Unfortunately none of their projects ever had to last very long and so as our team worked with them, we had to help them move from hackery to mastery.

It is very easy to throw together software proof of concepts that serve as a model for how the finished product should work. It is quite another to actually build production software that can hold up to the pressures of large-scale use. Think about something as simple as a database. While you are building a proof of concept, you don't have to worry about data loss. If something goes wrong, just reinitialize everything and keep testing. Put that same system into production and you need to make sure you are taking regular backups. If it is important data, you may want to leverage replication to a standby database that can be switched at a moment's notice. Then if something goes wrong, you quickly swap out the dead server for one that has all of the data and is still running.

Sometimes mastery can mean extending the development time significantly. This group I had the pleasure of working with didn't comprehend that. They couldn't understand why other parts of the company took so much longer to do the same thing they could do so quickly. Once we started educating them about all of the possible scenarios and what could go wrong, they discounted our advice. Then we moved from prototype to production and they saw that some of the concerns we had actually had merit. It only took one or two issues to arise before they started looking at things the way we saw them. Ultimately we all became software developers from the experience and that is part of the path towards mastery.