Wille Faler’s Buzzword Bingo

Picked up a nugget on TheServerSide, which I thought was worthy of highlighting on my blog:

Any serious manager will always go for standard solutions, such as JEE, simply because it is less risk.

Now, to play the devil’s advocate for a second: WHY is it less risk?
4-6 years ago, everyone went crazy for EJB’s because it was “a standard and hence less risk”. Now most people who adopted them are in a right mess: they can’t upgrade their JVM’s or app servers because it is too big a risk, they can’t improve or extend their codebase because it is too big a risk since EJB’s are almost untestable (and even if they where testable, good luck retro-fitting fitting tests on container-based code years after the fact).
On the other hand, anyone who went with writing in mostly plain Java have been able to continue on their codebase and update JVM’s & app servers to their hearts content.

Just stating something is “less risk” because it is a standard doesn’t make it so. Sometimes you actually have to think about what the actual, real risks are.

There is one thing that never stops striking me when I come across it: the vast gap between the value that good software developers/architects provide for their clients and employers, and the appreciation of that value shown by clients and employers.

It seems that most of the time, organizations are prepared to bite the bullet of paying quite handsomely for good software professionals, but if they can think of any way not to, they’d rather not: there seems to be some ingrained notion in many peoples heads that software development is somehow a menial and lowly task requiring little to no skill, that can be taught to anyone given a weeks “handover”.

I’ve seen this being expressed many times over: By having the highly paid, highly skilled people being divorced from hands-on development, instead being expected to provide “architecture” and “designs” for an army of lower paid, considerably lower skilled developers.
I’ve even seen cases where companies have given notice to their skilled developers, to then have them “teach” everything they know in a week to some offshore team that are actually web designers/html-jockeys!

As if knowing how to crank out a static web page with some text on it was the same thing as writing scalable software for integrating diverse information systems!

What seems utterly lost on people with this mindset is that skilled software professionals are highly paid for good reason: they have a scarce skillset that takes years and years to pick up and hone. Even the difference between an experienced, highly skilled developer, and that of a junior unskilled developer can be that the experienced developer can do things in no-time, that the junior developer would not be able to pull off given infinite time!

A good metaphor for this situation is that of trying to make a woman give birth in a month by impregnating 9 women - adding women to the equation won’t hasten the delivery, because the quantity of women is not the cause of the problem in the first place.
In raw economic terms, it makes more sense to pay a highly skilled person £600 a day to perform a task that takes him a week to finish, instead of paying 4 lowly skilled people £100 a day to perform a task that they will never be able to finish.

How this appreciation gap has come about, is beyond me, but I think it has to do with people thinking of software development as if it where conbeyor belt industrial production, whereas in reality, it is actually new product development - it is actually designing both the product, the conveyor belt, and the tools and processes around reproducing the product.

The Register reports that Barclays Capital is cutting the pay of their contractors by 10% over the board, those who do not accept the pay cuts will be allowed to work out their notice period.

I can sympathize with Barclay Capitals wish to slash 10% of contractor costs, but the way they are going about it is rather inept: they will annoy and alienate just about every contractor they use, which will hardly do wonders for morale, productivity and retention of high value individuals.
The fact is, some contractors may be grossly underpaid compared to the value they bring as it is, whereas others may be grossly overpaid or even surplus requirements. Why not try to identify the overpaid or surplus requirements contractors instead of using such a blunt instrument to cut cost?

..but then again, doing shrewd business moves can sometimes be hard work, and given the predicament that necessitated this move in the first place, shrewd business moves are probably not very high up on their agenda..

(Point of note: I do not contract for Barclays Capital, nor have I ever been affiliated with them in any shape or form).

A lot can be said about the current credit crunch - first and foremost central banks across the world in general, and the american Federal Reserve in particular have poured gasoline on the credit bonfire by means of artificially low interest rates, resulting in unhealthily cheap credit being plentiful. This is not a lesson the Fed seems to have learned anything from, now that they are again lowering interest rates and pursuing wildly inflationalary monetary policies that will only go towards rewarding irresponsible economical behaviour (spending more than you have on things worth less than you spend), and penalizing responsible economic behaviour (saving and producing).

But, blaming only the monetary policies and monetary system is short of the target, even if they have not helped the situation - it’s kind of like blaming obesity on McDonalds for selling Big Macs so cheaply.

The core problem has been a perverted incentive system in both retail- and investment banks coupled with weak checks and balances on risk taking:
Effectively, people in the banking industry have seen massive potential rewards in pursuing high risk, short term goals, but very small downsides if those risks would go haywire.

Let’s just examine the following example:
If you were to put $1 billion of someone elses money on the line on a very high risk gamble, were you knew that if it worked out, you’d be getting a $10 million bonus, but if it went all wrong, all that would happen would be that you got fired and could move on to the next employment were you would be faced with similar situations. Would you be inclined to take the great risk for the big reward, with the knowledge that the downside was very limited?

I think the answer to my question for most sane, rational people would be a resounding “Yes!”.

What is currently playing out is nothing more than the consequences of massively perverted and misaligned incentives between the employers and employees (the bankers themselves) on a massive scale.

If a companys goals are in complete misalignment with its employees incentives, disaster will always follow, it is as simple as that. The Federal Reserve and other central banks will probably keep their incompetent bumbling up for the foreseeable future, but the affected banks can certainly do something about reforming their screwed up and broken incentive systems .

Getting a large bonus should not be a God given right regardless of long term results, it should be a privilege and reward received for doing the right thing in the long term perspective, regardless of whether it means taking a few short term hits at times.

Over the years, I’ve taken part of a number of projects, some that I’ve been proud of being part of, some that have been forgettable to say the least. But even knowing the impressive returns some of my projects have reaped for my end clients, the thing I am most proud of is something completely different from something as simple as successful project deliveries.

The things I am most proud of is when I have seen real, tangible improvement in the skills, thinking, discipline and general standard of people around me, and I have known that I have at least played some part in their personal development. I guess not having kids, seeing the penny drop for colleagues, and having played some part in getting that penny to drop is the closest thing you can get to seeing your firstborn riding a bike without trainer wheels for the first time.

I believe that in the long term, being able to help develop the talent of people around you is perhaps even more important than short term deliverables: the ripple effect of others improving their level of proficiency is them in turn passing it on to future colleagues, with a cascading effect in terms of successful project deliveries elsewhere.

Learning from others, and in turn letting what you know rub off on others truly is one of the most satisfying parts of working in an industry that is demanding on your grey matter - and it is definitely a plus sum game if there ever was one.

People in more senior positions on software projects are often asked to make estimates, sometimes without consulting the person who (or even knowing, or knowing who) will develop a certain piece of software. This brings a few problems with if:
Firstly, not all software developers are equal, the most productive ones can be 10 times more productive than the average ones, not to even mention the poor ones. There is a very wide span of productivity - if you don’t know if it is Slow Steve or Productive Pete that is going to do the work, how can you give a somewhat accurate estimate with any level of confidence?
Second, even if you know who is going to do something, you don’t necessarily know their personal strengths and weaknesses as well as they do themselves - maybe Slow Steve is actually rather good at a given task, or Productive Pete struggles badly with a specific type of problem?

There are a lot of factors playing in that make making estimates for other peoples work littered with dangers that can create a massive margin of error in your “guesstimate”.
Personally, I’m a big fan of people doing their own estimates, on functionality that is sufficiently unambigous for them to make a reasonable estimate for - not only will you get more accurate estimates than your own stabs in the dark, but the people making the estimates will tend to get better at making their own estimates (at least if you check back and see how it went), all of which means your teams estimates as a whole will tend to become more and more accurate over time.

Integrity is a scarce commodity not only in business and politics, but in mankind as a whole. Most people are either too afraid to say “no”, or too focused on short term gain at any cost to possess it.

Having integrity is not easy, it means disappointing people, sometimes on a regular basis, and most people do not feel comfortable hearing things they don’t like, or saying things they know others do not like. Integrity can imply a number of things, for example:

• Do not promise what you are uncertain of being able to deliver.
• Do not pass the buck, blame others or grab glory that should belong to others.
• Acknowledge the contributions others have made to your success.
• Admit when you are wrong, but don’t dwell on the past - fix the future.
• Do not make compromises that compromise your own core values - be prepared to walk away, but don’t be a primadonna and drama queen.
• Do not indulge yourself in fantasies and wishful thinking - see your situation as it is, and deal with it.

I’m guessing most people struggle to tick even three out of the six boxes above on a consistent basis. Integrity may not always please people, but at least it will grow trust - people will know that your word is worth something, and that they can trust you come rain or shine.
But if integrity was an easy thing, it would not be such a valued commodity: it requires constant vigilance, self-awareness and an iron discipline. Even the strongest characters will succumb to the primal instinct of ducking responsibility and pleasing people in the short term from time to time. The only question is, what will you do and what kind of an individual do you want to be?

The above comic made me laugh out loud today - it is very accurate to the attitudes of a lot of people (myself included in the past). However “working harder” implies a couple of things, first that people are currently “slacking off”, and second, that people can maintain a consistent level of productivity even when working tired and under extreme pressure. If people are not already “working hard”, you are in trouble.

But the second point is more interesting: there seems to be a certain level of machismo around working long hours - it shows that you are a mans man, prepared to do what ever it takes to deliver. However there is a distinct diminishing return to working longer hours, to the point that it can actually become a negative return: many professions, like software engineering to take one close at heart, requires you to be constantly mentally sharp to be at the height of your productivity. Once fatigue and stress starts setting in that mental sharpness is gone with the wind, and people start making simple, stupid little mistakes that they wouldn’t do under normal circumstances.
Under short periods of time, long hours may work surprisingly well (people may be “in the zone” when they put their head down and just work hard), but in the long run fatigue and stress will take its toll. Obviously different people have different levels of productivity, stress tolerance and maximum number of productive hours in them, so giving a blanket number can’t be done - but on average I think the current 40 hour working week is pretty close for the average person in the long term (>2 months).

“Working harder” can only at best be a short term solution to solve short term problems - if it becomes the standard mode of operations, something is seriously wrong with the way your organization works.

The Register: “Rubbish UK management crushing creativity” (quoting a scientific study).

Nothing new there. For a country that culturally puts such a premium and emphasis on “management”, the average level of UK managers is really poor compared to my experience of other countries. If it wasn’t for immigrant managers and software developers, the UK IT industry would pretty much grind to a halt from general mediocrity and incompetence (the sad state of british software engineering is a completely different chapter altogether).

When I first moved to the UK, I was taken aback by how politicised the work place was: a general culture of “divert the blame, grab the glory” prevailed over true teamwork. After closer to 4 years in the country, I’ve gotten used to it, but unfortunately it has been confirmed to me that politics often takes the front seat to actual progress in many organizations.

Personally, I think the country’s obsession with stardom and football (soccer for you yankies) are partly to blame: the stature of managers attracts a lot of people into management who really shouldn’t be managers, and many of those in turn are either spineless pushovers that are just secretaries with fancy titles, or go one step too far by modelling their management style after macho authoritarian football managers.
The only problem with the latter is, there is a marked difference to managing a group of overpaid, pampered, uneducated and half-witted ball-kickers, and managing moderately paid intelligent professionals..

A lot of software developers scoff at the notion of “architects”, and often rightly so - there are more than a few snake-oil peddling, powerpoint totting guys in expensive suits being self important and micro managing development choices without actually having much of a clue. The fact is, when it comes down to software code level patterns, the guys best placed to make the calls are usually the developers. You don’t need an “architect” if you have a group of skilled developers that are comfortable with the concept of collective code ownership (not all developers are).

But while I don’t really see a need for architects on a project level, at “higher levels” I can see the need for architects: A team of developers on a project are surely the best people to make architectural decisions around the software they are creating, but when it comes to a programme of several interrelated projects the need for an “architect” starts becoming more apparent. The reason for architects being so generally disdained is that people do it all wrong - they micro-manage and give out dictats of how “things should be done” down to the tiniest little bolt, which is bound to rile people who are actually in a better position to make those decisions.

What an architect should actually do in this case is not try to dictate how things should be done down to the smallest detail - instead he should act as a gatekeeper of sorts by:

• Reviewing work “below him” to ensure it meets quality standards and make sure nothing sub par creeps through.
• Provide feedback for improvements and act as a sounding board for ideas.
• Ensure an appropriate level of commonality across projects - suggesting reuse and common architectural patterns where applicable and not obvious to the individual project teams.

Can you see how the “gatekeeper” approach is “bottom up”, rather than the old school annoying “top down” architect?
Given the enforcement of commonality across projects, even the gatekeeper will have to “dictate” some things, but the key here is to find the right level and not start micro-managing. For instance there is a big difference between saying “Our organization uses JBoss as our JEE server” and saying “All projects must implement business logic as EJB’s” (if you didn’t catch it, the latter statement is micro-managing and wholly inappropriate without a very specific context).

I guess the real stumbling block for any architect/”gatekeeper” is finding the right level for my third point - ensuring commonality, it is very easy to fall into a mode of micro-managing and butting in where your nose does not belong.
Doing the mental shift in focus from “architecting” to “gatekeeping” might go some way in fixing the problem - because gatekeeping is what it is all about.

To make an analogy to the Open Source community: the most successful projects don’t have maintainers that butt into and micro-manage every aspect of the work that committers and contributors do - they just ensure that whatever gets into their codebase is to a consistently high level of quality.