At our recent release planning session, I was assigned to a new project, which involves (among other things) exposing a CLI-based configuration interface as a web service. In our initial discussions, the four of us more-or-less agreed on a few initial decisions:

• The exposure should be REST. Fortunately the people developing the upstream system shared this opinion.
• Rails is an ideal framework for RESTful web services.
• Ruby seemed like a good fit for parsing the command responses too.
• Asynchronous behaviour would be handled using queues (probably ActiveMQ).

Since we’d all been working on Rails projects when the new team was formed, we assumed that this wouldn’t be a particularly contentious route to go down, but unfortunately our director/architect/boss didn’t see things quite the same way. He had two main objections:

• Rails may make sense for GUI applications, but why on earth would you use it for a service? All our other [SOAP] services are written in Java.
• At some point the application will need to go into support, and we don’t have support/operations people with Ruby or Rails experience

I think the first point’s easier to address, as I’d argue it’s based on a misunderstanding: Rails isn’t really anything to do with GUIs, but is a framework for creating MVC web applications. Virtually all the heavy lifting Rails takes care of is in the controller and model areas, with the creation of the actual visible GUI being left to the developer to take care of with the usual mix of HTML, CSS and Javascript. The only thing Rails adds is the ability to insert dynamic content using ERB – similar to the role of JSP in Java EE.

A RESTful web service is, to all intents and purposes, the same as a normal web application, but (potentially) without the HTML. All the power that Rails brings to web application development is also harnessed when creating RESTful services.

The second point represents a much more fundamental strategy choice. If the company makes the decision that all development is going to use Java (the language as well as the platform), then we inevitably lose the flexibility to choose what may appear (in a local context) to be the right tool for the job. Personally I think that would be a shortsighted and ill-informed decision: if that were the strategy, we’d presumably all still be developing in C, or COBOL, or Assembler. Or we’d have gone bust. But then I’m not an architect (incidentally, according to Peter Gillard-Moss, that’s reason number 10 why I don’t deserve to be fired), so what do I know?

However, if Ruby is considered an acceptable technology choice for “normal” web applications, we’ll still need people with appropriate skills to support those, so the problem doesn’t go away. I suspect even for a Java specialist, supporting a well-written Rails application with good test coverage is probably easier than supporting some of the spaghetti-coded Java I’ve seen.

Anyway, our arguments obviously weren’t totally unconvincing, because we were given a couple of weeks to show what we could produce before getting a final decision. That time runs out on Monday, so if I’m unnaturally grumpy after that it’ll be because we’ve been told to chuck all our work so far away and start from scratch in Java. Or possibly FORTRAN.

Update, 16 June Well we made our case, and we get to stick with Rails. Celebration all round!

I guess I'm fortunate to work for a company (and in a country) where by and large there isn't a culture of firing people who don't meet performance targets – instead we have a system where an ever-increasing proportion of people's pay packet is made up of a performance-related bonus, rather than a fixed salary.

So, how do you go about getting your bonus each quarter? Simple: just meet your agreed targets.

Of course, nothing in a large corporation can ever be that simple, so in practice there's a complex tiered system of company, business unit, programme, project, team and individual targets, which are combined in a magic spreadsheet to generate how much bonus everyone gets. Each of these targets, and the performance against them, has to be agreed, monitored, quantified, audited and levelled. At each stage politics comes into play. Those that enjoy playing systems try to set targets they know they can achieve. People concentrate on meeting the letter of the objectives, possibly to the detriment of other activities, like helping colleagues or making process improvements.

Now step away from this corporate dystopia for a moment, into the world of Agile Software Development. A world where we value Individuals and interactions over processes and tools, and Responding to change over following a plan. A world where we strive to build projects around motivated individuals, give them the environment and support they need, and trust them to get the job done. Where working software is the primary measure of progress. Where at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Where the self-organising team, accountable directly to it customer or product owner, is responsible for its own delivery and processes.

Now, when agile teams in large organisations are forced to jump through the externally-imposed hoops of objectives, development action plans and post-implementation reviews (which add little visible benefit and take up time that could be spent delivering business value), is it any wonder that the carrot of performance-related pay feels like it's more of a punishment than an incentive?

Technorati Tags: agile, performance management, enterprise, corporate, hr

Public domain photo from Wikimedia Commons.

Incidentally, a Google search for all lies maggots on toast currently returns Paul's tweet above the Wikipedia page for the character the words come from.

Technorati Tags: psd, twitter, hothouse

One of the comments he made that particularly struck me was to the effect that a piece of software is a living thing, but is parasitic, requiring a 'geek host' to live on. Much of the value of software isn't what it does, but what it can potentially do. Once you separate the software from its geek, it starts to die, because it can no longer adapt to changes in its environment.

I think this is something that we're losing in the world of corporate IT. In the old world the systems the business used tended to be huge, developed in-house, and come with a whole team of geeks attached. Unfortunately in those days we also had heavyweight waterfall processes which made it hard to react to new opportunities for the software to create business value.

These days the big systems tend to be assembled around so-called COTS (commercial, off-the-shelf) products from external vendors. In the real world, of course, COTS products rarely work 'off-the-shelf', so there's usually still plenty of code to be written. Since this is not considered 'core business', it gets farmed out to whichever outsourcing company puts in the cheapest bid.

The systems still have large teams attached, but somehow we lost all the geeks. The software's new hosts are programme managers, project managers, delivery managers, architects, solution designers and who-knows-what else. Actually interacting with the code is considered almost menial – something that can be done by anyone with the appropriate technical skills, regardless of whether they have any knowledge of the specific application or its business context.

It's much harder to unlock the potential in a piece of software when the people the business talks to aren't the ones who understand how the code works. It's even harder when no-one understands how the code works.

On a completely different note, it's embarrassing how low the turnout seems to be for events like yesterday's, and the talk by Martin Fowler and Dan North last year. Maybe people are just busy or don't hear about them, but I can't help thinking it's partly down to the fact that we just don't have many geeks left. On the plus side, at least it meant that those of us who were there got a decent chance to chat to Jeremy and Doc afterwards.

Amongst others, these paragraphs caught my eye:

"For Americans and anyone, it can be a shock to the system to be actually expected to make problems visible," said Ms. Newton, a 38-year-old Indiana native who joined Toyota after college 15 years ago and now works at the North American headquarters in Erlanger, Ky. "Other corporate environments tend to hide problems from bosses."

Worse, some executives like Mr. Konishi complain of managers at Toyota factories who have not adhered to some of the company’s most basic creeds, like allowing workers to stop factory lines when they spot defects. Empowering factory workers has long been central to Toyota’s quality control.

It strikes me that this is very similar to the problems faced when trying to introduce agile development into large enterprises. Managers are used to controlling what people do and how they do it. Developers, testers and designers have learned that when something goes wrong, covering your back is more important than cooperating to put things right.

In my experience it's also a big problem when trying to combine agile with outsourcing, especially to suppliers with a corporate tradition of command-and-control management (and – shudder – CMMI level 5). As Toyota have obviously concluded, the answer seems to be a combination of education with a very strong message from the top.