For all the talk of lighter, leaner Java web development things still seem to be pretty difficult. Not to say they are as bad they were in the J2EE days, but pretty tough nevertheless.

When you’ve had a look over what is available in Ruby on Rails you start to realise just how far even supposedly light Java frameworks like Spring have to go.

With Rails the easy stuff really is easy, and the tough stuff doesn’t look too bad either.

Where are the tools to make Java web development as pain free? The tools are there, the language is superb, no language has a better tool or library ecosystem. All that is needed is something to bind it all together into a cohesive whole.

Sometimes it is interesting to ponder the future of programming. And, like most future gazing it is almost always wrong. But, good fun nevertheless

One thing I believe is certain is that today’s arty/craft programming methods won’t outlive me (I’m 38 yo). Why? Mainly because they don’t work often enough. One thing business and governments want from IT in general is predictability. They want to have software delivered on time, on budget with the features they asked for.

Software production isn’t predictable. Some programmers/teams perform brilliantly some perform very badly.

If I were to hazard a guess where things will go I would say that software development will come to resemble hardware development in many respects.

Take a look at tools like this. That looks a lot more like hardware development than traditional software development. I’d hazard a guess that artifacts created with the Cogitron tools could be verified for correctness by the software itself.

From my experience working in ISDN, the hardware people seemed a whole lot more predictable than the software people. Their first deliverables were never perfect but they were a lot closer than the software deliverables. They took a lot fewer iterations to reach a shippable deliverable too.

One of the most frustrating things about software development is the politics.

You would think by many programmer’s attitude that all is a bed of roses…that systems are delivered on time, to budget and with all of the features you asked for.

And of course software isn’t a bed of roses, in fact it couldn’t be much further from the truth.

So against the background of failure you would assume that programmers and their managers would be open to new tools and techniques that improve performance.

Well, you’d be wrong. Programmers are amongst the most technically conservative group of workers you will ever meet.

Which is a pitty. There are proven tools and techniques around that do improve software quality. The biggest problem may be that customers are far too accepting of poor software. So, market forces don’t weed out the cowboys.

I like this blog about software by Dave Winer…all software is shit. The only difference is the software vendor. Some vendors admit it, some don’t. The ones who don’t are deluding themselves.

All software is buggy, period.

So, find software vendors who admit their software is shit and are determined to fix it.

Wordpress is shit and I love it.

On the deployment side of software development, one of the trickiest aspects is deciding which versions of Microsoft Windows you plan to support.

From the logs of this and other websites I manage, it is obvious that there are a wide variety operating systems in use. But, how can I, as a software developer, support software running on an operating system that itself is not supported?

I’d argue that you cannot…but that won’t stop customers expecting it anyway

When Windows 2000 support is finally dropped, then there is just going to be XP, 2003 Server & Vista to worry about. That doesn’t sound too bad until you realise that there are two XP versions (Home & Professional) and, oh, loads of Vista versions.

As soon as you remove Windows 2000 from your support list then that opens up some nice new Microsoft technologies for you to work with like .NET 3.

Of course, the Windows 2000 support issue is likely to be less important for home users. Most business users are likely to be more sensitive to support issues than home users, they are also less likely to be sensitive to upgrade issues because of price pressures. Many medium/large Windows users will have the right to OS upgrades as a part of their broad Microsoft licences. So, upgrading from Windows 2000 to XP or above won’t require them to give Microsoft any more money.

My suspicion is that there are an awful lot of homes still running Windows 98, so if that is a part of your market then you’d better support it. That will then feed back into the types of development tools you can use.

So, you need to start from the deployment platforms and then choose the development tools not the other way around. Unless you want seperate products for legacy platforms and Microsoft supported platforms?

Architecting IT systems is hard. Figuring out which technologies are worth investing your time and effort into is a complex process.

You’d think it would be a simple process of selecting the best tool for a particular job. Not really. Things are a little more complex than that.

Utilising a technology takes a lot of effort and expense. It takes a long time to become “manual free“. To stay manual free requires constant contact with the technology.

Therefore, if you utilise too many technologies you risk never being manual free.

Whatever the technology, the main productivity gains are to be had when the people using it are manual free. In other words, they can just get on with the job at hand without having to figure out too much about the underlying technology.

So, sometimes you have to decline to use technologies even though they may well theoretically be a more productive solution.

I’ve just had to make a decision like this myself. We need to re-work an area of our site. Add a database backend, add an admin section etc etc…all standard web requirements. What would be perfect for that? Well, Ruby on Rails sprung out to me as an obvious choice. I’m sure it would to a lot of other folks too.

So why did I decide against adopting it? The main problem is that I would never be manual free with it. I would struggle to solve my problem, never being really productive because I don’t know it well enough. Then, when I had done my makeover I might not touch the system again for six months. Any knowledge I had won would be lost to me. So, I’d be starting again wth those manuals

Instead I am going to be using Java + Spring. Not as productive perhaps as Rails but at least I already have some investment in it. Our e-commerce system is already written in it so I will be using it on a continuous basis. So when I become manual free I will retain my knowledge better too.

One of the hardest things when unit testing is retaining discipline. I have a nasty habit of refactoring code and then fixing something else that is completely unrelated to the job at hand. I find it really hard to stop tinkering.

What then happens? Well, your tests go red. You then find yourself trying to figure out whether the tests are failing because of your initial refactoring or your code tinkering.

One potential remedy might be continous integration. Perhaps, if every time I checked in changes and the system refused because of broken tests then maybe I’d be able to stop myself tinkering. Unfortunately, for now we are doing ActiveX components in ATL/C++. There is very little tool support for continuous integration in the Visual C++ world.

Role on .NET…we’ll be there soon

I found a bug today. Quite a biggie too. Not something that will happen everyday but nevertheless it will happen.

We are currently working on a software development kit for a range of temperature sensors we sell. We have a unit test suite with around 80 or so tests give or take. The tests cover what you’d probably expect. Read the sensor, make sure the values coming back are what you know should be coming back.

We created a mock sensor so we know precisely what should be coming back.

I was trawling through the code writing some more tests and it occured to me that I couldn’t see anything in the code that handled what would happen if the sensor’s owner randomly changed the default temperature units on the sensor. Now, that isn’t going to happen very much but it will happen and the code as it is will get it wrong.

So, I am going to have to write a test to cover this scenario. It will fail…and then I can fix it

But the point is, no amount of unit testing + code coverage analysis would have caught this scenario. The code didn’t handle the scenario, therefore there is no code to cover so to speak.

In the end, it is still down to the designer/developer to properly analyse the problem and create a correct solution taking into account all of the boundary cases.

Read a great blog by Alberto Savoia about developer testing. Alberto discusses what the future of developer testing is likely to be. He suggests that the future of any developer testing may be in doubt. Which would be a shame.

Programmers are far too happy shipping sub-standard software. We need all of the tools at our disposal to increase quality. Developer testing through unit tests has got to be the best single task you can do to ensure software reliability. And the best thing by far is that you can keep running the tests whenever you make a change. So, your tests just keep paying back time and again.

Hard to see how you can argue against it…plainly many programmers do. Anyway, according to Alberto’s developer testing gene categorisation I am a T1: highly susceptible to test infection.

Everybody seems to be using virtual machine based languages at the moment. And with good reason. Java and the .NET family of languages are certainly productivity enhancing, though not for the obvious reasons.

The main benefit from the new virtual machine based languages are that, relieved of the burden for deleting objects we are suddenly more productive. It’s not an argument I buy into. Not many people writing C++ get to delete their objects manually. A combination of the C++ Standard Library and Boost have seen to that.

The main benefit to me are the tool sets surrounding both Java and .NET. I’ve never seen a richer ecosystem of tools like IDEs, profilers, build systems, unit testers etc, especially supporting Java but .NET is catching up too.

What’s more, most of the tools are available for little or no cost. Most notably the wonderful Eclipse IDE.
C++ doesn’t have a broad ecosystem of tools. Performing unit testing and continuous integration with C++ is arduous. Most programmers don’t bother.

It is a pitty, C++ has a lot of strengths. I love writing it…though I suspect that may be a minority opinion.