You are currently browsing the monthly archive for February 2009.

The big divide at work (for me at least) is between the hacker coding style of development and object oriented engineering. I’m in the OO camp, and my two superiors are in the hacker style camp. I’ve been working on the hard sell of trying to change how we develop as a team, and frustratingly enough, I don’t seem to be making much progress. Good thing I’m stubborn.

What I call hacker style is a method of development where getting things to work and out the door is the primary goal. Time spent thinking and planning development is limited to small scale, low level, single function planning. Nothing is really orchestrated, and the “system” is more of a patchwork of processes that when run in the right order, perform the overall tasks as though it were actually a whole. The focus is on speed, and being able to do new things.

Now, I don’t have any problem with that in general as there’s a trade off when moving to a more thoughtful, and deliberate OO style of development, which can have a real positive or negative impact on business. And for startup companies, hacker style is the preferred and probably optimal style of development. Business demands require speed and getting things out the door, so you can finally have a proof of concept that generates real revenue. Spending extra time to choreograph the whole system is money lost that’s hard to replace when you’re already on a shoe string budget.

Admittedly, I work for a startup, but it’s a startup with real revenue (million of dollars of revenue a year for multiple years with continued growth), and I’d says it’s in a transition between the “we’re still a startup” and the “we’ve got revenue streams to worry about” stage. The engineering team to date has done a great job doing what needed to be done. That’s something to be proud of, but now the code base is old and messy.

If there’s anything to be said about my last job, it’s that I’m experience in old and messy code (I’d include my time at Citigroup too, but the code was just old, not as much messy). And I’m definitely experienced in leading a development team to a more appropriate style of development. I personally prefer a more deliberate OO style of development, but my last job needed more hackers. Still, OO can be implemented with great successful if you have the right experience in earlier stages of the game. With this my new company, which is a little bigger, they’re about at the end of the hacker stage as I see it, but they’re holding on tight.

With a team of good developers, how do you transition them from being hackers to engineers, and what is the benefit of an OO approach to engineering as well as the business? As your code base grows, its complexity grows. Maintenance, scalability, adaptability, once corner stones of the hacker style, now become elusive and out of reach. Even with well build systems, things get old and messy. From my experience, most systems only last 4-5 years before needing a good overhaul, or the business risks losing it’s ability to change and respond to new situations. Developer time gets lost to fixing bugs and time gets eaten up by the many workarounds that inevitably happen when implementing additional functions and features.

The ultimate goal of OO design is building an intelligent code base. Intelligence is not a measure of behavior like most people think. Intelligent is an understanding that allows one to predict future events. A code base can “predict” future events by understanding what is likely to change in the future, and having that part designed in a way that makes changing it easy. You don’t make everything easy to change, but that which is likely to change. You need to manage the complexity of your code or it’ll blow up in your face.

People who aren’t familiar with OO design, or aren’t experienced with good OO design (it’s easy to screw up if you don’t know what you’re doing), they may see OO as more complex and slower to implement. When transitioning between development styles, in the short term that may well be the case, which is why startups generally don’t do OO design unless they’ve got some special previous knowledge in the matter. But as complexity grows, patchwork systems lead to more bugs and a more complex interaction that will drag down a development team, and in the extreme, can cripple a business’ ability to react.

One of the main pieces missing when doing hacker style development is a big picture view of the system and the various interactions. As the system was developed in pieces, the patchwork of functions were developed with limited consideration of other existing functions, and usually no consideration for upcoming functions. Without a big picture view, you can’t pull yourself out of that patchwork. You need a guide to get yourself to a better position.

There’s an additional drawback to the patchwork (utility class) design. Because it focuses more around processes and less around object relationships, it’s impossible to discuss the parts of the system. Engineers will be forced to learn from the code instead of other engineers. Additionally, as the code base is process focused, you’re code will give as much if not more weight to dealing with edge cases. This is part of the reason why engineers have a tough time discussing such existing code because you can’t generalize and talk about the overall interactions, but instead are caught up mulling over special cases.

The benefits of OO engineering range from greater ability to react as system complexity grows to better team communication as you move away from process acted upon multiple complex objects to relationships between a common set of objects. Getting a team to handle this change properly requires a map, but also vision and a mission.

Businesses have two functions. Marketing (PR, advertising, sales), and invention (engineering). The marketing side of the business will most certainly have a set of ideals such as VMOS (there are many varieties of this), vision (the dream), mission (what you’re trying to do in the next couple years), objectives (focus or important metrics for accomplishing the mission), strategy (lines of action for meeting your objects). The highest level long view down to actionable strategies. Engineering needs a similar plan that describes how they’ll implement the business’ VMOS. The engineering VMOS will reflect the business’ VMOS, but translated for engineers and around the act of inventing instead of marketing.

Somewhere in the objectives and strategy level, you can setup a diagram of your system. Not how it is today, but how it should be tomorrow. This’ll be constantly changing, but it gives engineering a way to communication, and a guide for how to develop. Where do you spend the extra time planning? What is really an at risk area? What functions are important to keep on the radar?

OO engineering can easily break down without a plan, but also without a leader. Just as the graphic design team will have a head designer who will pull together the design and keep it looking like one common design, engineering needs a head engineer to pull together overall development as though it was actually done by one person. Since any problem can be solved in 20 different ways, you need someone to short cut the discussions, and make a decision even if it doesn’t look like the best choice to everyone. Just because you’re given more room to plan and think deliberately, doesn’t mean you can waste valuable time not getting code out the door (I’m not advocating a waterfall approach mind you).

This gives the engineers the tools to both communicate and predict. With the high level ideals defined, you can develop a plan for transitioning. How do you meet business demands and still maintain and improve the code base? It’s laid out in the engineering VMOS. Without this, all you can do is react to the nearest term demands and situations, which becomes tougher and tougher the more patchwork and complex the code. The engineers are the protectors of the code, and they must always be mindful of that while they get pressure for more from the business, so you can’t let the marketing side make all the plans and call all of the shots.

Wrapping this up, both styles work with the variety of agile development approaches. Both styles have value for a business at different stages in it’s life. Both can be good or bad if you go too far to an extreme. Balance is key as is so much in life. In the case with my current job, moving to OO engineering removes much current and future complexity.