Wille Faler’s Buzzword Bingo

In private conversations, I have occasionally put forward a thesis that the software industry could cut its workforce by 50%, and become more productive in the process.

The reason is fairly simple: firstly, the industry is full of organizations that use counter intuitive heavyweight development processes that hinder work more than they support it. To be perfectly blunt, in organizations and projects that subscribe to this model of software development around 50-70% of the tasks, and by extension roles are complete and utter bulls**t. The tasks and the roles are simply a waste of space, nothing more, nothing less.
Secondly, even when it comes to the roles that in theory actually would make a constructive contribution to projects, they are often filled by people that are a waste of space, although it has to be said that the organizational problem and inefficiency is by far the largest problem.
Thirdly, even for those who do contribute productively to the outcome of projects, most projects tend to have a small minority of key people who contribute and outsized amount to the end result - one often quoted figure (which I cannot remember the source of) I recall states that the most productive developers are 10 times more productive than the average ones (that’s “average”, not “useless”).

After 8 years in the software industry, I think I can say with a reasonable level of certainty that most software development organizations (with the exception of those that are already disciplined) would be able to cut 50% of their workforce and get more done, provided they could have the discipline to do the following:

• Streamline work and emphasize “people over process”. Employ people who have effective habits for their job instead of trying to ram down committe created processes down the throats of people with ineffecient habits.
• Recognize your top performers, let them have the freedom to do what they are good at, and retain them at (almost) any cost (someone who is 5x more productive than an average person is still a steal at twice the salary of the average person).
• Cut the dead wood unceremoniously. No “ifs”, no “buts”, people may be “fun” or “nice”, but if they’re not pulling their own weight they should go. Fun guys can probably find work at the local comedy club, and I hear there are lots of openings in childcare for the nice guys.

The problem with the industry is that most organizations do the complete opposite: they retain the dead wood and let them run the show, they emphasize mind numbing process over the ingenuity of people and they do nothing or very little to recognize and reward their top performers (a lot of the time, they don’t even know who they are).
The software industry would do well to take a couple of pages out of Jack Welch’s book on how to rate your people..

As a person I have two great gifts - I’m extremely lazy, and I have a very short attention span (which makes me very intolerant of long, drudging meetings and politicking).

I consider these two traits a gift and a big asset, and I’ll tell you why:

Laziness is a virtue
Being lazy in a rational way, with the long term in mind means a couple of things: I go to great lengths to avoid duplicating work and I try to automate mundane and boring tasks wherever possible. Doing things that can be automated is a waste of time, and so is doing the same thing over and over, or even worse, fixing things that went wrong the first time around. It may sounds counterintuitive, but being lazy actually makes me more efficient and thorough the first time around as I try to find the shortest, most elegant path from A to B. Being hasty and rushing things will almost inevitably end up meaning you will have to do twice the work to fix the things that didn’t work out.
Lastly, being lazy means I do not exert a lot of effort trying to predict things in the future that I cannot realistically predict: I am aware that there are big unknowns in front of me that need to be mitigated and dealt with, but I won’t waste time (or more preciously: energy) trying to exhaust every option and avenue when I know 90-95% of them will be for nothing.

A short attention span is a blessing
If a meeting is longer than 15 minutes, chances are my mind will start wandering of in the direction of day dreams, if a document is longer than five pages of dense text, my eyes will probably start glazing over by page six. Having a short attention span means that I am pretty good at cutting to the chase and finding the core of a matter: I know I don’t want or have the time to read an essay when a paragraph will do, I like problem definitions that are short, solutions that are simple and explanations that are brief, devoid of excuses and chit-chat, but call to action.
I’d rather spend my time solving problems and creating solutions, than reading about them or engage in debate about them. Don’t take me wrong, I like small talk as much as the next guy (probably even more), but small talk is small talk, business is business.

Just paying a salary to employees has a strong draw for companies: any surplus value created by the employee is a profit for the shareholders. But personally, I think just paying employees a salary is problematic in most industries where you cannot enforce a steady level of productivity (such as manufacturing).

For knowledge- and service based companies, a plain salary for employees is probably the surest way of making sure that the organization slowly starts rotting from within.
Let me elaborate a little - In knowledge- and service based industries, I feel it is crucial that employees motivations are aligned with those of the organization, it’s goals, values and bottom line. Any assymetries of motivation will show itself in a number of ways, which most people can probably relate to:

• People will work “just enough”, and won’t put in more effort than is expected of them. Unless your employees are half-wits who enjoy the ungrateful task of being unpaid pack mules, this will happen.
• If you still push your employees beyond “just enough”, the word “push” will be what is remembered. People will become disgruntled. What’s in it for them?
• People will start spending the company’s money in ways they would never spend their own money: frivolous expenses, project spending out of control and spending more aimed at covering individual behinds, than being cost effective.
• Prestige takes presedence over profits: people will put their personal prestige over anything else. Politicking will pervade and unprofitable projects and endevours will not be cut even if there is nothing else at stake than some individuals personal prestige.

These are just a few examples of what will happen if people only have a salary as their sole motivation. Sure, some (probably quite a lot of) people will see personal prestige, professional pride and integrity as further motivations, but if peoples motivations are not in line with those of a company, all of the above will start to pervade within the organisation sooner or later even if you have 20-25% of employees being top performers.

Traditional salaried employment in knowledge industries is simply uneffective and bad - don’t be surprised if costs run out of control and profit margins dwindle if a salary is all you give your employees, the reason is very simple: your employees simply do what is in their rational self interest, and those interests are not the same as yours.

Most people like to think that they are somewhat rational, yet in real life 95% of people will not face the facts, even if they get slapped hard in the face by them. Looking at any of the property development TV shows in the UK will give you first hand examples of this: half-witted people wanting to try “property development” break every rule in the book - they build their “dream home” at a price over the odds, instead if building for their buyers. They hold out for prices the market just won’t carry, because they look at how much profit they want given their spend, rather than the other way around. The list goes on and on.

The same thing is pervasive in IT projects, startups and large organizations alike: a project may slip, have setbacks  and everyone will know in their heart of hearts that the project will never hit its original deadline, yet the original deadline is not moved one bit until that last minute “oh shit!”-moment. Sound familiar?

Wishful thinking may be one of the most destructive forces we have in our minds - optimism is a good thing, but it should be coupled with realism. Wishful thinking will only make you drive your car straight of the cliff into the abyss. Don’t think for a second that “what you want” to happen will happen just because you want it, it never will.

Do annotations “pollute” interfaces and objects?
A common objection to annotations I’ve come across is that they add “coupling” to objects, or that they “pollute” interfaces. I’ve also heard these as the basis for arguments asserting that the use of certain annotations should be restricted to a given tier, for instance JPA annotations should not be exposed to the web tier. I beg to differ. There are a couple of things to understand about annotations:

• Annotations are metadata, not new object behaviour or interface properties.
• Annotations are only processed by parts of a system that knows how to process a given annotation and tries to do so. If annotations are present, but not processed by a part of a system, it is as if they didn’t exist.

What the above to points imply, at least in my opinion is that you shouldn’t worry about “backend” annotations being present in the frontend, or vice versa: yes, it does potentially introduce a (somewhat unfortunate) transient but unused runtime jar-dependency, but it does not actually “couple” an object harder to any part of a system, nor does it change the objects behaviour or public interface.
A lot of the time, annotations are simply the old struts-config.xml, validators.xml and *.hbm.xml files attached to an object instead of a file in a jar-file. You wouldn’t worry about an object displayed in the front-end having hibernate mapping xml-files in the backend, so why would you worry about having Hibernate/JPA mapping annotations in an object in the same case? If it’s just a dumb bean, it’s just a dumb bean.

So when should I use annotations?
I’d say there are a couple of cases where annotations make sense:

• Replacing .properties and xml-config files: when annotations can be used in a clean and non-convoluted way as an alternative, for configuration information that is essentially part of the software and a deployment. Annotations are however an inappropriate replacement for configuration when it comes to configurations that may need to be changed dynamically during runtime.
• Supporting cross-cutting concerns: I’d say annotations are in a way “aspect orientation, less the actual processing of aspects”. Annotations are an excellent way to do things like dependency injection, service discovery of managed objects, validation and many other similar things. Where ever aspect orientation could make sense, but you don’t want to go all out and actually use an aspect oriented language addition such as AspectJ, annotations could be a viable option

When should annotations be avoided?
Whereas annotations have many useful uses, they also open up for potential abuse. A clearcut sign of annotation-abuse is when people start using annotations where they would otherwise have used an interface or an abstract base-class.

The points in this post is just a superficial look at annotations, but drawing from my personal experience of using annotations more or less heavily in the last year (and making a couple of mistakes along the way), I’d say these points are among the most important ones noting.
The misconceptions, abuses and uncertain areas of applicability I’ve raised are common sticking points for many developers, hence the “guide lines”.

The open source community and the Linux community in particular have brought a lot of good things to the software space, in fact I’d say open source is one of the bigger drivers of innovation, both in terms of technologies and business models.

However, following the comments around internet forums and blogs regarding the Ubuntu laptop related hard drive bug points to a very fatal flaw in the community, at least when it comes to it’s more vocal and immature members: A lot of very vocal people are quicker to try to assign blame elsewhere than fix bugs, and quicker to resort to name calling than to learn and improve from criticism.

Take the Ubuntu laptop hard drive bug as an example: most forums have been quicker to try to assign the blame to hard drive makers, than actually do anything about it. Is it the hardware makes fault? Probably. Should the Ubuntu community do anything about the problem anyway? You bet! Microsoft or Apple wouldn’t be getting away with not doing anything about problems that may destroy hardware, why should the open source community be any different?
The bottom line is, the original “fault” may not be yours, but the problem exists, so you would be better served by fixing it instead of assigning blame.

This brings me to my second point: some vocal minority elements of the open source community seem to have a very juvenile and immature way of responding to criticism, I actually have a few friends that have been driven away from trying Linux, due to the hostile nature of responses they have received when asking “stupid” questions in forums. Linux isn’t Windows or Mac, but that doesn’t mean anyone who isn’t a rocket science should be ridiculed out of town.

The point is ridiculing people, name calling and trying to assign blame isn’t very constructive, it won’t win you any friends. Even if it isn’t “your fault” (honestly: I don’t care whose fault it is), there’s nothing stopping you from actually doing something instead of resorting to finger pointing.
For open source to be taken seriously in the consumer market, it’s proponents need to grow up, drop the unjustified elitist attitude and step out of the sandbox. Far from all open source proponents are afflicted by this “sickness”, but an unfortunate amount of them are.

I’ve previously been very sceptical to First Person Shooters (FPS) on consoles: I own an Xbox 360, and I have to say that the highly acclaimed Gears of War bored me to tears after giving it a shot for several hours, and I gave up on Ghost Recon: Advanced Warfighter after about 15 minutes. So today I thought I’d give FPS on consoles one last chance, by trying out Call of Duty 4: Modern Warfare, to check whether I really need to get a gaming PC to enjoy 3D games.

To my great surprise, I found CoD4 to be probably the most immersive and enjoyable experience on the Xbox 360 I have tried so far! The graphics are great (especially on a 40″ 1080p LCD screen..), and the controls are similar to other console FPS’, yet more well balanced, or at least that’s the way it feels. I’m not sure whether Call of Duty is just head and shoulders above other FPS games on the Xbox I’ve tried, or if it turns out that FPS gaming on a console is an acquired taste. I’m honestly quite confused at the moment.

Anyway, I’ll pass on dismissing consoles as FPS gaming devices for a while yet, and I might give Team Fortress a chance in a few weeks time, to see if CoD4 was just a fluke, or if I’ve actually acquired the taste and skill to play FPS games with a console controller. I hope it is an acquired taste, because not having to shell out £1500 on a gaming PC is a pretty good boon..

Update
I played through the single player campaign for Call of Duty 4, and I have to say it’s a brilliant game: not only is the gameplay varied and interesting, somewhat unusual for an FPS, the storyline is also very engaging. The story really isn’t a super clean story with you as the hero: there will be times where you barely hang on, and if you get to the end of the game, the last few events of the game will surely leave you with mixed feelings (and I mean that in a good way) in the way that it captures that even in victory in war, you can be left with a sense of loss. Highly recommended!

“Software As A Service”, or SAAS has been a hot thing over the last couple of years, and it does hold a lot of benefits: no need for management or maintenance, automatic updates, (hopefully) automatic backups, very transparent and predictable costs and much, much more. A lot of SAAS products are just webified versions of existing software, with a few improvements, whereas other types of SAAS products owe their whole existence to the Internet, and would not have been possible without it (most notably many applications where collaboration is a central part).

But, there is one very important area where SAAS tends to fail miserably: continuity.
A SAAS service can and will only exist for as long as it is economically viable and profitable (in some way) to its vendor. If a service is a loss making proposition, and does not show any signs of being turned around most companies will cut it quicker than you can say “lost data”.
This poses a very real problem for SAAS customers: if a service is important or critical for your daily operations, how do you safeguard your data and investment in a SAAS service? Remember, you don’t own the infrastructure or IP for the service, so if it is cut, you’re out of luck.

In my mind, the hierarchy of trustworthy software goes something like this:

1. Open Source software: you can access the IP, change it and control how you want to use and develop in the future - the risk is very small.
2. Proprietary software: support and updates may be cut, but at least you own the initial license, and the right to continue using the old software and it’s data as long as you can and want.
3. SAAS software: see above..

This doesn’t mean I think SAAS is an entirely bad idea, just a risky one: I personally use some services that I find useful. But my point is, that you should think twice before trusting critical parts of your business to a SAAS platform, and if you do you should take very careful precautions to safeguard your data and investments, so that you always have an exit route, should the vendor cut or dramatically change the service.
Finally, SAAS vendors would do well by trying to be transparent about both their plans and their platform. Providing data export services or functions would go a long way towards this. Doing this may lower switching costs for their customers, and may not be in the immediate obvious interest of the vendor, but then again providing transparency and a sense of security for your clients may actually draw more new clients than it enables old clients to leave..

Software development methodologies are one of the most worn out, yet most heavily discussed subjects in software development. I tend to lean in the direction of a “just enough process” methodology, which has a heavy leaning towards a lot of agile practices, but without the religious fervour that seems to surround it these days (have you tested your tests that test the test-test-tests?).

The development process of any given project tends to be heavily influenced by the direction taken by the original core team of developers: Once you have started going down a road, it is usually hard to change, because coming into to a tightly knit team 4 months down the line of a 6 month project you’re not really in any position to change things around dramatically in terms of the ways things are done. You can influence the direction slightly, but a dramatic overhaul? Not a chance, unless the project is in deep, deep trouble. People just don’t like having a new guy come in and tell them they are doing it all wrong, it just never works.

By the same characteristics, development process decided by management dictat is also bound to fail: saying from high up and above that “you will now use XP/RUP/whatever” doesn’t work. It needs to be implemented at the hands-on level, and become ingrained into the way people do their daily work. A memo from management won’t achieve anything.

That brings me to my point: changing the way people work is hard, you can do it, but it requires people to have the talent for it, the willingness to do it and the willingness to change. That’s why people are really the most important factor in any development project. I’ve said it before, and I’ll say it again: I believe the right people, well motivated will get the job done.
Reasonably talented, well motivated people will find effective ways of working together and achieving their objectives.
In most cases, that means a good project team won’t follow some ideal state of a theoretical process or methodology, ever! The methodology the team will use will be implicit and largely unspoken: it will be based on the amalgamate of common sense and best practices the team members have come to understand over their worklife experience.

The best things in life are free. And by that same token, the best development methodologies in software are largely the product of good teams and motivated, skilled individuals spontaneously finding out what works for them as a group.

This evening, I have been e-mailing back and forth with two friends in separate e-mail conversations. One is in New Zealand and his friday was just starting. Another one is in San Francisco, she’s getting ready for her thursday lunch. I’m soon about to go to bed and it’s thursday evening.

Three people, different sides of the planet, different lives, times and even days, two of them don’t even know of each others existence (prior to this blog post). Yet I know them both well and communicate with them with the same ease as if they where in the next room.

The world is certainly getting smaller. The sense of proximity to someone is no longer about geographics, it’s about communication.