Archive for April, 2010
Software companies are modelled like armies… but are missing a thing
Posted by Lieven Doclo in Opinion on 2010/04/30
When you think of it, a large software company can easily be compared to an army. Let’s see if we can cover the ranks.
Infantry soldiers
This one is easy. These are the mainstream software developers. Like soldiers, some have specialities, other are just plain cannon fodder. As in the army, they can move up the ladder.
Lieutenants
These are your senior developers. They have experience, or have had more schooling which enables them to enter the company higher on the ladder. They should be able to cope with responsibility and make decisions that affect the performance of those they manage.
Senior officers
Like any organisational structure, the higher one goes up the ladder, the fewer in numbers. These senior officers are the management within the company. You’ll find majors (unit managers), colonels (divisions manangers) up to generals (CEO’s) and any rank in between. These are the guys that should be able to make the hard decisions. It’s impossible to enter the army with these ranks without experience, just like a company. You won’t start your career as a CEO (unless you start your own small firm, but then this article doesn’t really apply anymore).
Intelligence
In the army, intelligence can mean the difference between success and failure. In software companies, intelligence can be seen as the analysts. They build the blueprints that ultimately will decide if a project will succeed or not. As with intelligence, most of the work is done up front. Once the operation (project) begins, their main objective is to provide steering and updates to the situation at hand.
Engineers
In the army, the engineers pave the way and provide logistical support to the army. In a software company, these are your system administrators. They make sure the hardware keeps running and provide logistical support where and if needed.
I think that covers about all the positions within a company. However, software companies are lacking something crucial. The US Army has the 75th Ranger Regiment, the US Navy has the SEALs. We need something like that.
Rangers and SEALs are the elite. They are deployed when all other options have been depleted and the situation demands for a quick and professional intervention. When they go in, they get the job done.
In my opinion, every large software company needs one of more elite teams, depending on the size. The decision to deploy these elites should not be taken lightly: it’s expensive. As it should be. These are experts in their field and are a force to be reckoned with. When they make a decision, there shouldn’t be any second guessing (client or company). You’ll be giving these guys carte blache to reach the objective. In other words: you shouldn’t use these guys for putting out a small brushfire. No, you deploy these guys when the whole forest is on fire. You’ll be counting on them to put the fire out, utilising all and any resources they have (including all of the above ranks). Like the army elites, you won’t be using these guys when there’s no crisis. Like, say, transferring them to an active unit because otherwise they’re just costing the company money (that said, given a large enough software company, they’ll be occupied just about always). No. You make these guys train. Hard. You make sure they keep being the best of the best. You do regular checks to weed out those who shouldn’t be in the elite corps anymore and make it very clear among the members of that team that they shouldn’t take their place for granted. Even worse, you make dismissal a very public affair within the company. You make sure they are instantly deployable, anytime, anywhere. When the job is under control, you bring them back and let the main army handle the rest. You don’t keep these guys around for the fun of it. At most, you’ll leave a couple of elites behind a bit longer so they can make sure a second intervention won’t needed.
The client also be aware of the capabilities of such a unit. It’s very tempting for a client to always demand the use of such a unit once he knows it exists. After all, all the clients want the best team to get the job done. However, and this should be made very clear, the use of the elites should be at the discretion of the company, not the client. Their job is to defuse a situaton.
Why don’t companies do this? It costs a lot of money and most think they don’t need such a team since all their developers are elites. I would say ‘keep dreaming’. Any software company large enough needs teams like this. But maintaining these teams is expensive and hard. You’ll be paying for a lot of training, not to mention the wages. You’ll have to be at the top of your game to retain these guys and keep them happy.
All in all, I think it’s a nice idea I would love to see being used in real-life. If you work in a company that has such a team, feel free to share your experiences.
Ensuring transaction safety when using the MySQL/JPA+Hibernate/Spring mix
Posted by Lieven Doclo in Frameworks, Spring, Testing on 2010/04/28
When using JPA, using transactions is something one might take for granted. However, when you’re using MySQL and you’re not in control of the database, you may find yourself debugging a really hard bug: transactions that aren’t properly rolled back.
Read the rest of this entry »
Switching from C3P0 to BoneCP: mind the numbers…
Posted by Lieven Doclo in Frameworks on 2010/04/22
Now and then you want to hit yourself. Or shoot yourself in the head. Like I did today.
Recently, we’ve been experimenting with BoneCP. Mainly because C3P0 isn’t really Java 6 compatible anymore, but also because I like the multithreaded nature of BoneCP. Alas, I forgot to do one thing when switching to BoneCP: look at the documentation of the configuration options. See, C3P0 has timing for idle checks, database checks and so on… When I switched to BoneCP, I just reused those timings, since they worked nicely for the setup we’re using.
The catch? Well… C3P0 uses second or millisecond timings, BoneCP uses minute timings. Ouch. So what did we learn today? Measure and read, don’t assume. I for one won’t make this mistake again.