My CSM (Certified ScrumMaster) trainer is probably going to kill me after reading this title, as one of the things she kept repeating during the CSM course was that you don’t sell Scrum, and as such, pricing strategies . You sell a product to a client, and Scrum is a means to an end to get that product to that client in the most efficient way possible for all parties involved. Scrum focuses on content, early delivery and providing as much value as fast as possible. It also factors in the certainty of change. Read the rest of this entry »

Web clients are hot. Hip. Sometimes even hype. But having worked on different projects, both fat clients and web applications, I’m starting to grow a consciousness on when a web application is appropriate and when the choice for a fat client would be a more sane one.

Fat clients have a bad reputation. Deployment issues being the main culprit here. With web applications, you just deploy it on a server and every user has instant access to the application. Fat clients, for example using Java Webstart, need to be installed on the local client. They also require a JVM. Updating is not instantly, but requires a restart in most cases (unless for example you’re using some fancy modular architecture that allows updating on the fly). From an operations standpoint, fat clients are maintenance burden that isn’t popular. But Java Webstart has evolved, and in the light of that evolution, perhaps it is time to re-evaluate our behavior on defaulting to a web client. Read the rest of this entry »

Devoxx, the yearly appointment for Java geeks is upon us again. And off course I’m attending. As I have for the last 4 years or so. Being from Belgium and a Java programmer, it’s a practical no-brainer. For those not familiar with Devoxx, it used to be called Javapolis (but due to some dark political games, they changed names). It’s mainly split up w 2 parts: a two day University, featuring 3 hour in-depth talks and a three day Conference, with 1 hour talks which are more practice driven.

The first day of the university I chose two talks. The first one was called ‘The Productive Programmer’ and was about how to improve productivity as a developer (and a plug towards the book off course). A lot of obvious stuff in there, but always nice to hear the things I need to be productive are in there. It all revolves around ‘flow’. Being able to sustain a level of concentration in which you can do tremendous amounts of work. Like an interruption-free period of day. Like dual monitors on which you can display all the information you need. Like not having to use the mouse. Somehow I expected a plea towards Vim. Rates slightly under Uncle Bob’s talk last year about craftsmanship and ethics (and that says a lot).

In the afternoon I went to see the Spring Roo talk. I tried Roo in the past and wasn’t that impressed. This demo showed me some opportunities in which I see Roo flourish. Not in enterprise application development. It’s a wee bit to young for that and I don’t think that the mainstream development world is ready for the likes of Roo and it’s ITD’s (try and explain that to a 20-year Cobol-converted-to-Java developer, or worse, the army of offshore Indian developers). I do see a really big potential in prototyping. Being able to reverse engineer any database schema into a bunch of JPA entities and then build a complete (although somewhat basic) web GUI around it, seems really nice when you quickly want to show a client something that works. If you want to expose the database through a REST interface, this is done in a matter of minutes. As I said, the web UI is fairly simple (it does have complete CRUD capabilities with pluggable security, i18n, …) and won’t suffice for about 99.9% of your clients. But it’s a nice feature to be able to talk to a client, connect to its arcane database and whip up a RESTful web UI in minutes.

So far for day one…

If you want to comment on my articles, please do so. However, all comments need to be approved by me, so please adhere to the following rules:

• Use a valid email address
• No profanity or name calling (“YOU SUCK!!!” falls under that category)
• No spamming

If you follow these rules, I’ll approve even the most disagreeing comments (please read this if you want to disagree in style: DH levels).

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.