blog.frantically.org

This week has been a strange week. Mostly, it seems, prescribed by Conway’s law:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

I got quite excited when Paywave was launched in the UK and got a combined Oyster card with credit card and PayWave from Barclaycard. You can spend upto £10 by waving your card against a small reader in a shop without a PIN. It’s designed to be a cash replacement with a low per transaction cost given to the vendor. So cheap in fact that the adverts suggest you buy your newspaper with it. So far so good? I think so.

My newsagent has a sign “60p charge for credit card transactions less that £10″, presumably because they don’t do enough volume to get a good discount in charges from the banks. As PayWave isn’t exempt, the Saturday morning milk run would cost £1.05 using Paywave, adding 130%. A Japanese lunchtime takeaway near my place of work charge less, adding only 5% to the bill.

I asked the vendors and they think they are right. Barclaycard think the charges are incorrect but, having asked both, neither will try to change the situation. So what happened?

• - VISA didn’t do enough research to see that we, the customer, wouldn’t like paying a large percentage more on a small transaction?
• - VISA didn’t train the stores to treat it differently from a normal credit card?
• - The stores are trying to take advantage of the situation and take a profit?

I’ve stopped using my card as, despite many retailers charging the correct amount of £0.00, I don’t want to think about it and I’m guessing many others will do the same. Good product, bad rollout.

According to Barry Schwartz on Ted Talks, we’re happier when we have less choice. If we go to a store and they only have three pairs of jeans you can choose from, you buy the best fitting and leave the store knowing you did the best you could. When they have twenty pairs to choose from, you walk out unhappy that the jeans you have are not the perfect pair of jeans, despite being better than any of the three you used to be able to buy. You start to blame yourself rather than the store.

Well… last weekend, in an attempt to move away from Microsoft Windows, I decided to try and build an old PC as a LINUX Media box, to play videos on my TV. I’m actually sad to say that following this experience, in it’s current state I can’t see LINUX becoming a widely spread desktop O/S used by the world at large as the sheer number of choices available prevent ease of use and aid resentment.
I was amused to see this blog entry on more organisations moving to free operating systems immediately following my failure. Maybe I just didn’t try hard enough!

Choice #1
Which LINUX? Suse, Ubuntu, Fedora (to name a few)? I have no idea. 30 minutes on google and all I can find are a load of comparisons that conclude “all distributions have advantages & disadvantages, it is up to you to make a choice.” I can’t. I don’t have the knowledge. I pick Suse because someone somewhere mentioned it was popular in Europe.

The 3.1Gb install doesn’t work on my PC.

Thirty minutes on google and apparently I could re-compile the kernel to make it work. Not going to happen. Another hour on google and I try maxcpus=0 as an install option and off we go.

Choice #2
Which Desktop Environment? Gnome, KDE? I don’t know. I’m sure KDE will work, I’ll take that one please.

Choice #3
I want to play a video to see if it works. Someone recommends VLC. Perfect, no choice. Well not exactly. I can configure my YAST Software Management tool with a variety of software repositories that have SuSE packages installed on them. Currently the default repositories installed with the O/S don’t have VLC. Even when I’ve made a decision on a piece of software, I still have to choose how to get it.

It works! And my old PC springs to life and seems to have plenty of CPU left to boot. It was worth all the effort.

Choice #4
What Media Client should I use? MythTV. Easy no choice again, I just want a client that plays video through my TV and can be used with a remote control. Off we go. Well not so fast. It’s here that the devil is in the detail. Having spent an hour struggling with various repositories to get MythTV and it’s dependencies installed, I look for an icon to click to run it. There isn’t one. Google points me to Wikipedia:

[MythTV has] A backend server and frontend client architecture, allowing multiple frontend client machines to be remotely served content from one or more backend servers. A single computer can perform as both the frontend client as well as performing as the backend server.

Apparently I’ve not installed the client or server yet, just the basic stuff. My next steps are to install these components and then choose how to configure them. I don’t want to, I just want a “typical install” to get me up and running.

It’s getting too hard, my next choice is easy.

Choice #5
Windows Media Center Edition or LINUX running MythTV (if I can get it working). Windows MCE it is. One hour later it’s up and running perfectly.

LINUX has and will continue to bring a lot to the world, often due to individuals prepared to give up a significant proportion of their free time. But without effort spent on polishing the basics and reducing the options available to the user, it seems unlikely that it will break into the marketplace currently dominated by Microsoft.

I suppose unsurprisingly, I’ve had a few jibes that go roughly like this recently:

No posts since November, not exactly frantic!

A fair point. However, to put the record straight, frantically.org was selected to represent my state of mind when madly typing away at a keyboard, rather than a statement of regular posting. When I do get passionate about something (as everyone I work with has to tolerate), I do tend rant away or type loud enough for everyone around me to hear whilst I work my way through an idea.

Anyone in either a position of responsibility or the face of the customer often has to defend policies that they may not agree with. I felt I had to share this one because of it’s great lack of ownership or ability to question the insane.

I’m sure there are many reasons that someone in the know could share as to why such a rule was put in place but the conversation above followed another one I had of similar nature:

Apparently by default the sorting office do a bad job, it’s only when they get reminded to improve that things really go smoothly. Either way, I quickly changed address on anything I could think of and never received another piece of redirected mail. However, the new occupant of my old address may not have been so lucky.

From a variety of sources, this blog on the 5 Principals for Programming came my way. Two bits really grabbed me:

We know that c/java/lisp/haskell have not one bit of power that isn’t in simple assembly langauge–they only allow us to express the ideas more clearly and prevent certain kinds of stupid mistakes. There is no program that can be written in one that can’t be written in another, and all end up as machine instructions sooner or later (some at compile time, some at run time, but no matter). Given this fact it should be obvious that the only reason to have a programming language is to communicate to a person.

Absolutely, we could write in machine code but we choose not to. Why?

1. To make it quicker to write code.
2. To make it quicker to understand someone else’s code.

Often it’s too easy to concentrate on the first and forget the second. The less code we write, that clearly explains the problem it is trying to solve to another reader, the better.

But more often [as a developer], I know the best solution but it requires changing things. In my experience every single factor in the software development process will argue for doing the wrong thing: schedules, managers, coworkers, and even, when they get involved, customers.

Here I’m torn. Previously a developer and now manager it’s easy to shift focus from development problems to those of the customer. And the balance is hard.

There are certain tools that should always be used in development to create a system that is as flexible as it needs to be. These should be selected on merit but no matter what, the set will include tools for unit testing, repeatable builds, easy deployment etc. I’m assuming these are not up for discussion with the customer. We are employed to stop the customer having to worry about these details.

However, when using these tools, it’s easy to become caught up in the beauty, or purity, of the code we produce. But this beauty is not why we, as producers of software, are employed. It’s functionality is. Decisions on when to incur the future cost of poor implementation should not be made by developer alone. It’s easy to be upset when requested to do something less beautifully, and this is a good thing. Failing to understand the reason why it is important to do so is another thing.

I suppose the question becomes, “what choices regarding how software is produced should the customer get?”

It happens to most applications. Eventually, the time required to implement new functionality becomes so long that it can’t be justified in terms of cost. This leaves the customer with two options:

1. Put the application into RTB (Run The Bank) mode. i.e. keep the existing functionality but don’t add any more. “The new things I wanted weren’t that important anyway.”
2. Keep the application in RTB mode whilst embarking on The Big Re-write. “I need more than I have so I suppose we should start on Version 2.0.”

In either case we fail to deliver what the customer actually wants. Even worse, The Engineering Trade points out that embarking on The Big Re-write is selling the present to buy the future. Considering that the customer only wanted a small addition in functionality this is terrible, they’ve already waited for the application to be written once.

Clearly it’s never possible to write an all singing, all dancing application that guessed all directions the customer may choose to go in the first version. However, I can’t help but think that we in IT aren’t good enough at using a few basic rules to avoid The Big Re-write.

Make sure you actually know what the customer wants

Spend time understanding what the customer actually wants. It’s far too easy to assume the customer needs more than they are asking for. There’s a good chance that the most complicated parts of your application are the bits catering for requirements that didn’t exist. By never creating these complications in the first place, the application will last longer.

Write your application with well defined components & interfaces

1. Make sure you create well defined interfaces around and within your system. Doing so will allow you swap out the bit that doesn’t work or scale anymore, more easily.
2. Understand that the interfaces on these components will change and create a development environment that supports this:
• A team that isn’t scared of change.
• Lot’s of automated tests.
  

Components, like applications, will have the life-cycle depicted in The Engineering Trade. However, a set of components that pass well defined data between each-other should be easier to replace at a lower cost than replacing the entire application.

Monitor the functionality

As an application gains stronghold with it’s users you’re on a roll. You’ve gained some kudos and want more. Requirements that don’t really fit the application come your way but what the heck. How bad can it get? Stop! If a new requirement doesn’t really belong in the application, find somewhere that it does. Trying to have the most comprehensive application in town won’t work in the long run.

Creating an environment that allows the low cost introduction of new, small applications will benefit all.

Evaluate what you have without bias

Before embarking on the The Big Re-write, stand back and do a proper evaluation of what you have. Try to find ways to separate what appears to be a monolithic application into components and then replace the problematic ones.

It can seem all too easy to re-write an application when you’ve been complaining about it (well the original designers anyway) for so long but the stigma alone shouldn’t be a reason. I’m not convinced that enough of us are prepared to try and properly understand what we already have in-front of us.

Don’t get me wrong, with all the above, re-writes will be necessary and you can’t create hundreds of applications that each service one function, requiring the user to start them all to do their job. However, if applied in right way, these practices minimize the number of re-writes at no functional cost to the customer. Therefore, surely, they must be a good thing.

The opportunity cost involved in “selling the present to buy the future” is not an option IT should present to the customer. It is the job of IT to deliver software that meets this requirement.

Recently we’ve seen a load of anti-agile commentary. For example:

Good vs Bad Agile
Obie’s Comments on Pairing (via Tom)
The Death of Agile

To add my tuppence:

Software development exists to service the needs of a customer. Being religious about agile does not aid the customers requirements, neither does ignoring it. Know why you are doing what you are doing.

Assuming that development practices fall broadly into two categories:

Organizational Practices (Planning & tracking)

Those practices that ensure the software you produce is the right software:

• It’s what the customer wanted.
• It’s not more than the customer needed to do their job effectively i.e. they were able to do what they needed to when they needed to be able to do it, rather than have the capability to do more than they needed to later than they needed to be able to do it.

Technical Practices

Those practices that ensure the software produced is produced in the right way by the developers e.g:

• Test Driven Development
• Pair-Programming

I do not believe either set of practices should be implemented blindly. Attributes within each should be taken on merit:

Selecting Organizational Practices

• If you believe the best way to produce software in your organization is to write a specification, get it signed, develop, test & deliver a year later, do it.
• If your customer’s needs are better suited by an iterative prototyping development style, do it.

Selecting Technical Practices

• If you believe that your team is currently characterized by non-fungible developers who hold too much knowledge in one area, pair-programme to share knowledge and reduce risk.
• If you have junior team members who need assistance to become more productive choose how to do it:
• Give them a book and send them away
• Pair-programme to bring them up the curve with a real problem in-front of them.
• If you know one common component is critical to the future of the system and really don’t want bugs in it, pair-programme to get a better result.
• If your development team need to pair-programme in order to concentrate on the task at hand, determine why, don’t blindly pair-programme to avoid the problem.
• If your customer needs software out there NOW, weigh up future maintenance cost against the slower delivery of a system that has greater test coverage and is better designed, and take the appropriate decisions:
• Stop or start pair-programming
• Determine what an “acceptable test coverage” strategy is for your release

Do you or your customer choose the development practices to meet their needs?

For the last few years I’ve worked for an investment bank that has prided itself in it’s attitude towards technology. In hard times, we created a environment that introduced many new collaborative tools. This in turn led to many people hosting internal and external blogs.

… and here we are after a few years of reading other people’s views I’ve finally launched myself into the blogging world. If I’m looking for the tipping point, Malc’s post on The Engineering Trade was probably it, but constant conversation with Tom regarding the state of project management in IT has to be up there too.