I’ve been a little bit quiet on the blog front recently because I very happily have got a job as a C# developer, after quite a bit of time away from work by choice… and then a fairly long job search. One of the fantastic things working for a small consultancy (<10staff) was proven in the first few days; I had coded some small enhancements to the system… and they had gone live!Furthermore, despite a low score on the Spolsky ‘12 simple rules for software development‘, and also the Atwood ‘Programmer’s Bill of Rights‘, in a very perverse way I rather enjoyed sitting on a hard chair, hunched over a laptop with a single small screen whilst sharing a desk. Fortunately, that was just for the first couple of weeks – we’ve now moved offices now and we do indeed have Herman Miller Aeron chairs, and thankfully our own desks!

Anyway, this post is really about the pros and cons of the low-overhead development style that my company uses. By the end of my first week, I had in fact put several changes and enhancements live. How’s about that for productivity? Certainly they were not major changes, and the user-base for this particular app was a small company, so the ability to test the new feature in live was a real and pragmatic option. You’ll notice that we are not talking ‘Extreme Programming’ or ‘Agile Processes’ here… we are talking virtually no processes <grins>.

There is a lot of vibrancy in this approach. If I’m making a change in a live database, I need to be really careful about the change I make; I have to make sure that I do the right thing, first and foremost; and in addition I need to be sure that what I am doing will not have a performance impact or other system impact on the client, or the client’s customers. The same goes for code and code-releases too. Furthermore, there are obvious benefits for the client:

• Their business is growing and changing rapidly; they are rarely certain about what they really want on their first request… we can implement what they think they want and mean, and then we can revise it to their taste quickly;
• We can respond quickly if surprising events occur that need us to investigate, because we operate on informal rather than formal processes.

Despite the exhilaration of knowing that my efforts were counting for something so quickly, it does not take long to see some of the problems with the approach too:

• The client has rarely had to wait long for work to be done, so a good percentage of the work items are highlighted as ‘high priority’… that’s fine as long as we don’t have bigger, longer running projects that are impacted by the interruptions! And of course, as the business grows, the system tends to gain in complexity and the projects will inevitably have more impact and potentially more side-effects;
• A very short QA process prior to going live is fine at the moment; the bespoke system is mission critical but controllable for now… but as the client grows, the ‘mission critical – only more-so’ nature of the system will take a higher priority;
• Because releases occur very frequently, source control becomes a regular, almost daily, chore. At any point, your own development could halt because someone says they’ve updated something on the source control. A refresh of your local copy could reveal a conflict (ok – so that is good to resolve early) – but it is bad from the point of view of changing your focus from what you as an individual perceive to be the task-in-hand.

I’m enjoying this challenge in many ways. It reminds me of what I understood ‘Rapid Application Development’ to mean back in the days of Delphi v1. The talk was of development teams doing a release, getting feedback from the client, and then immediately and quickly responding to feedback and coding the changes ready in just a day or two! Nevertheless, as this system becomes even more critical, changes will tend to become more substantial.

As my company and our client grows, we’ll have to address some of these issues and come up with mechanisms to resolve some of these issues, without adding too much overhead. Not only am I enjoying being a programmer again, I’m enjoying the prospect of being able to help enhance our procedures and systems in the future. I’ll be referring to the sources noted at the start of this blog, but I’d be really interested to hear if anyone else has ideas on what we could do to change.

A Surprising Source of Problems

A recent short project for me involved working with a major and well-known payment-services provider (PSP) company that involved changes to the way we handle credit and debit card payments. We received a specification document from them for a new web service; but the document was incomplete; for example it mentioned return values from the service but not any exceptions that might be produced by the service. It mentioned parameters for one function that it did not mention were returned by another source (and how they were passed, etc). I’d asked our contact on several occasions for more detailed documentation, and an example implementation in html plus any other language. Consistently, they neglected to provide anything else.

And then, during testing, several points and problems were raised in my implementation that could and should have been in the documentation we were supplied. I have to admit, that really annoyed me; I just did not expect that a company providing a service would be unwilling to elaborate on how that service should be used, and in addition, the surrounding issues like ‘after taking a payment, we expect you to present details of our payment reference to the user’.

Hypocrisy?

Is it hypocrisy to highlight flaws in this relationship with the PSP, when clearly ‘specification’ is not a strong point in my own company?

I don’t think so. If our main client chooses to want a responsive approach to their work, they pay for the time that we spend implementing it. They get some benefits from that approach, but they also pay for the down-sides too. When a major PSP takes the same approach, all the companies that have to use that interface pay the price – and in fact the PSP pays a price too in that they will spend more time answering questions and testing implementations.

It’s simply crazy – and once again highlights the different mindsets that different programmers and developers may need to have. If you work for a software company producing class libraries, your mindset may be orientated towards keeping a consistent interface… whereas if you produce a piece of software for ‘end users’ usability may be a priority, and so on.