Websphere… omg

I just had my first foray into getting a simple war running in a WebSphere application server. Wow – what a nightmare. Man I hope i never have to do that again… what a waste. Just awful.

What’s worse, because it’s so ironic, it’s a spring boot based app which runs perfectly with with ‘java -jar …’ using the embedded tomcat, or jetty, or undertow.

 

The arrogance of Gantt charts

Gantt charts, popularized by Microsoft Project, are a mechanism for managing projects. The idea is that you list all the tasks required to complete a project. You then estimate how long each task will take. Once you figure out the dependencies between the tasks you the layout a plan from left to right connecting up all the dependent tasks. This allows for some parallelism between non dependent tasks. Given the project start date and all the durations you get the project end date.

As long as everyone sticks to the plan, then the project will be completed on time.

Simple, eh? Err – not so fast! The major flaw is that Gantt charts are task focused so when a new task is discovered the project is guaranteed to be late. The reason behind this is that developers are focused on delivery of the tasks they are assigned – not value to the client. Coupled with the truism that tasks will take as much time as they are given and you will be late.

The task-centric approach only hints at the real problem with Gantt charts: that better planning and task discovery up front would have resolved these issues. This is the most deplorable aspect: God-like wisdom can be achieved and would have fixed the problem.

Historically, software development has used the notion of “defined process control” where all aspects of the plan can be controlled, to a low-level and to a high-degree of accuracy. This does not work for most software projects because software development is not a simple undertaking- it is usually a complex process where small changes in the inputs can greatly affect the outcome.

Big, upfront planning that depends on infinite wisdom does not work and the only mechanism we have for complex problems is Empirical Process Control. This is the notion of frequent inspection and adaptation to a process.

Emperical control is _the_ key to Agile software. You’re not are Agile if you don’t have a regular process for improvement – you’re just hacking away.

Gantt charts have no place in an agile process; they are the tool of bluff used by the project manager that really doesn’t understand software development.

We only hire the best

I was recently having dinner with an acquaintance who works for a massive multinational IT company. He was telling me that at a recent company conference that, despite the economy, the CEO said the company was doing well because “we only hire the best”.

I almost choked on my steak, trying to contain myself. The sad thing was that he actually believed it. How come all companies that I’ve worked at only hires the best ? Surely all of them can’t have the best ?

Why do companies maintain this illusion ? Is it some sort of psychological trick so you don’t quit and join a company full of bozos ? Or do people at the top truly believe it, in some sort of paradoxical delusion ?

I don’t know, but it’s odd isn’t it ?

Routing around damaged processes

It is often said that “The Internet interprets censorship as damage and routes around it”. I don’t know how true this statement is, but I have seen this affect applied to organizational processes.

When you work at a sufficiently large organization, you’ll start to employ people who’s sole responsibility is creating process. The problem with these roles is that, if no new process is created, then those people are not seen to be doing their job.

Once they get started, there’ll be a process for each aspect of developing software, production releases, production data changes, process for creating a process, etc. etc. ad nauseam. (I’m not saying that there is anything wrong with processes, but more that it unsustainable to continue to create them indefinitely).

This usually has either two outcomes:

  1. good people who just want to do their jobs get fed up with the red tape and leave or;
  2. people “route around the damage“d process.

I see #2 happen all the time. The problem is unnecessary risks are taken because it has just gotten too hard to do anything.

How do you solve this ? Ideally, the people that author the process should also have to follow it themselves. At the very least, you should involve the people that have to follow the process in its creation.

The most important thing is, you have to make following the process easy and fast. If you slow people down, they will just route around the damage (you!).

Passionate About Programming

Today I bought The Passionate Programmer from the Pragmatic Bookstore; this is the 2nd Edition of My Job Went to India: 52 Ways to Save Your Job and has been re-targeted more clearly at becoming an ‘awesome developer’ rather than ‘doing enough to not get fired’ which the earlier title implied. While buying this I was distracted by a post on The Pragmatic Life blog called Share Your Passion which inspired me to share what it is that makes us (the bloggers here) passionate about developing software. BTW: So far the book is great – thanks Chad.

There is synchronicity at play here; when we started this blog the other day we were toying with subtitles and one of the ones we considered seriously was a tongue in check ‘awesomeness codified’ (personally I still like this the best even though I didn’t come up with it :-P). Part of the reason we started this blog is to put stuff out in the public domain to get feedback. To reach out to people who know and understand more than us in the public domain and to share what we’ve found to those close behind us on the curve. We are hoping to get the sort of feedback that will help us move closer to ‘awesomeness’ in software development. We also want to have a place to whinge about things we find annoying :-P.

Each of us is near the top of the chain in our organisation; we have broad and deep skills in many areas of the Java and Java EE space and have been around the block many times in both successful and failed projects; we’ve been shouted at, we’ve worked all night, gotten depressed and received accolades and glory. Also, a large part of our experience has been in banking – which has it’s own world of pain points but can also be a glorious industry to work in for a software developer.

Obviously you take the good with the bad – but how have we kept our heads above water (psychologically) during the bad times – it is because we are passionate about what we do and deep down we are still enjoying the cut and thrust of software development it even when the poo is hitting the fan.

We were discussing recently how much we enjoyed one night a few years ago where we were in the office all night and most of the next day (after a full days work too) because of the intensity of the situation that the business was in. Basically we received in one night far more volume than was expected and we had to ‘massage’ it through systems that were in their infancy and in no way ready to scale to the level of data we had to process.┬áRegardless of how we got into this situation (obviously in an ideal world we might have planned better) we had to now manage it and were on the critical path of a successful or failed year end process (i.e. make or lose lotsa money). This meant that we had some very senior executive director level people in the business right down to the current season of graduate interns and us all working as a unit, in the zone, to get over the line. It was stressful, difficult and tiring but we felt a part of something; we were able to display skills and aptitudes in a very visible way and deliver results instantly, not just the results in managing overburdened systems but in joining business decisions using peripheral skills gained in building software for the business we were a part of. It was an environment of mutual trust and respect with everybody intensely focused on a positive outcome regardless of position or role in the business. This is awesomeness codified.

Anyway, back to the point – we want to become ‘awesome developers’. This doesn’t mean ‘they who know the most api calls in the java.lang package’ or ‘they who can make JBoss sing the national anthem – in a language of your choice (while washing the dishes)’*; it means we want to love what we are doing and to inspire others (in the space) to love what they are doing; it means we want to be able to deliver robust, reusable, reliable and ‘awesome’ solutions better and better every time; it means we accept that someone will always know more than us and that we will strive to meet those people that we might incorporate what they know into delivering better and better solutions; it means we want to be a part of and understand the businesses we work with and within, again so we can deliver better and better solutions; it means we want colleagues (it & business) to say ‘wow, they really care about what they do’.

So this is why we blog. We want the feedback; we want to attract developers who are already awesome – though they may not know it – to help us improve. However, to be brutally honest maybe we just want to be famous :).

* we can though, well – maybe not the dishes bit.