10 Questions to ask before Changing your Software

It's been said that modern day software engineering is like gardening in that you're not normally creating something new but maintaining an existing system.
So when gardening - when making changes to your existing codebase - there are several questions to ask:

1. Why am I Making the Change?

The best code change is no code change at all - because every code change carries the potential work of a bug fix waiting to happen.
The smaller the code or configuration change, the lower the risk. If it ain't broke, don't fix it.

2. Who is the Customer?

Are you making the change because your boss thinks it would be a cool new feature? In which case he's your internal customer (this is often the easiest case as it matters less when the requirements aren't completely defined up front).
Or is it that there's a real, paying, external customer who wants something added to their bespoke software package?

3. What are the Use Cases?

Once you know who it is you're developing for, you'll need to know exactly how they plan to interact with the system...

4. What are the Detailed Customer Requirements?

...and what those new UI components should do under the hood.

5. How will the Architecture be Affected?

Will the change affect your software's architecture? Are you just adding a new widget to your GUI, or are you going to rewrite half of the existing code?

6. Which Existing Modules need to Change?

You do have a modular codebase right? Yeah? So you'll need to think about which ones need to change, and how.

7. What new Modules are Needed?

Will that new widget require its own module, or does the functionality sit naturally in an existing module?
If new modules are needed, what's their public interface and how do they interact with everything else?

8. How will Errors be Handled?

How does the software cope when the inevitable happens and the user does something stupid?
Or the robot that you're driving decides to crash into itself?
What happens when the web service that you query falls over because a pop superstar passes away and there's too much web traffic?

9. How do we test it all?

As this is a change to existing system, you need two types of test:
1. Regression tests to confirm that the existing system still works.
2. New tests to test the new stuff.
If the software already has an automated test suite you've covered 9.1 already and covering 9.2 should be a doddle.

This is also the place to look our for deficiencies and commonly experienced problems, for instance, if you have a highly multithreaded codebase, how do you make sure that the delta hasn't introduced a deadlock?

10. What are the alternatives?

Double check that the change you've decided to make really is the best way before touching any code.

What do you think? Is there anything that you disagree with? Or that should be added to this list of gardeners' questions?

Clustering keywords for meaning

After a couple of occasions when Google has totally let me down, I've been thinking about the problem of improving search engines. And particularly about the problem of meaning in a search time.

For example, when you Google the term Ultralight you are presented with, amongst others, ultralight outdoor gear and ultralight aircraft as Google has no idea which you are interested in.

Flickr gets around this problem by clustering results together - compare their ultralight cluster.

Perhaps this is more of a problem with using short, relatively meaning less search terms, something we've been conditioned to do because search engines just don't understand natural language. Yet.

Pair programming with Google Wave??

Google Wave was announced the other week and seems to be making ripples (excuse the pun) amongst technology bloggers. I recommend readers who know nothing about it to watch the video as I'm only going to talk about one aspect:

Pair programming with a Wave Extension

Wave is all about collaboration. Collaboration and extension.

And it won't be long before extensions exist to compile your favourite language. Then, its real power will be presented to developers.

Imagine coding in C++, pair programming with a legend like Herb Sutter or Scott Meyers?

(I'm sure that all they'd require is a convenient way of charging ;)

How to hit the Front Page of DZone. But why it Doesn't Matter.

I've been lucky enough to hit the front page of DZone on a number of different occasions and I believe that there are several tricks that can be employed to reach the holy grail, the front page.

Captivating or Controversial Title

DZone readers spin through hundreds of new links everyday trying to find something new or interesting to read. As a blogger or link submitter, you have a dozen words or so to captivate their attention and get their valuable click.

The title you choose should give them measurable facts, because what coder can resist indisputable fact? E.g. 6 Free Tools that every Windows Programmer should Install

Or, the title should provoke controversy, such as Should Coders be Allowed to Wear Headphones at Work? Make it a subject that most programmers have an opinion on and they'll click on the link just so that they can add their comment.

Quality Content

You can't find a post on blogging that doesn't mention quality content. So, I shall to!

Seriously though, people will only give it the DZone thumbs up if the article is well written and delivers what the title promises. Obvious really.

When to Submit

I've not yet hit the front page from a Monday submission. I think people must be just too busy on Mondays to promote links. Tuesday to Friday is best.

But why it Doesn't Matter

Chris Guillebeau over at the Art of Nonconformity argues in his excellent manifesto, 279 Days to Overnight Success, that you don't need to hit Digg (or indeed DZone's) front page to make a living from blogging.

He says that if you're trying to make money from Adsense - and he reckons that this is quite a difficult task - then you need that constant stream of visitors that Digg (or indeed DZone) can provide. But if you're trying to build a fan base interested in your compelling story then those sites won't help.

Multi-threaded JavaScript Makes Stream Processing a Reality

The future is finally here:

Multi-threading in a JavaScript app.

Wow!

Do you realise what this means? It means websites could use a form of stream computing to get your computer to do stuff without you even knowing.

It means that a website sending out processing requests to every browser that hits it - without said browser becoming unresponsive - is now a reality.

And as JavaScript engines become more efficient, this will be even more of an option.

The web-based super computer is amongst us, if a site where users tend to stick around for a while, such as Facebook or Myspace, wants it to be.

Let me just explain that last point - Facebook et al (or, indeed any web site) could send packets of data to your machine for it to process in the JavaScript enabled web page without you even knowing it. The answer to the processor-intensive question would then be sent back, and the web site gets its result.

It could even sell this processing power!

Is it legal, I think so.

Is it ethical, well, that's for another debate.

Motivating Geeks... And non-Geeks Part II

In How to motivate Geeks... And non-Geeks I talked about not de-motivating by getting the basics wrong.

So, time has passed and you've got the basics nailed, your hygiene factors are suitably hygienic, where do you go now?

Well, now comes the motivators: Respect, Truth, Openness, Trust, Responsibility, Recognition, Achievement and Growth.

I learnt some of these the hard way, like the time when I used to make computer games and I was technical lead on a new PS3 development, I told a developer who'd been programming since the ZX Spectrum days how he should go about finding and fixing a bug.

He sturnly replied, "Yes, I know!"

My comment - at the very least - broke the Resposibility and Recognition rules. And probably the Respect rule too.

There's a common misconception that salary is a motivator. This is wrong. A decent salary is required to stop people worrying, and you won't be motivated unless you have enough money to pay the bills, but an increase in salary is not equal to an increase in motivation.

Be honest with your staff, give them responsibility and then trust in them to do a good job. Share with them how the company is doing, ask them how they're doing. Tell them the truth.

Then, and only then, will they really excel.

Motivating Geeks... And non-Geeks

Maslow's hierarchy of needs and Herzberg's two factor theory both say the same thing:

You need to get the basics right before you can expect your staff to be motivated.

If workers are scared of losing their job or frightened of not being able to buy food for their children, they aren't going to be motivated.

When people get annoyed at their unresponsive PC and tediously slow compile times they aren't going to be motivated.

It won't help if they're in pain because their desk or seating area is wrong. Or if the temperature is sweaty-forehead-hot or freezing-nose-cold.

When there is excessive noise they won't concentrate, and won't care.

If bullying occurs or workers feel undervalued they'll just not bother.

Pay attention to the little things. Ask your staff what they need and what they want, and you'll be well on your way to a motivated workforce.

Motivating Geeks... And non-Geeks Part II

Is Programming a Creative Pasttime? Discuss.

Martin Amis missed a trick when he called his book The War against Cliché. The War on Cliché would have been far more apt.
"What has a book on literary criticism got to do with software development?" I hear you question.

43/365 - That's So Cliche! FGR
Originally uploaded by AMooseinBrighton

Well, programming is often said to be a creative pasttime. And when I was developing video games I would have totally agreed with that statement.

But now, with some years of professional development in non-entertainment-software circles, I'm not so sure that it is.

Beautiful software is built from well structured reusable components that adhere to design patterns.

The design pattern is the programmer's cliché, in that the world has seen it all before.

So when you're thinking about being creative and coming up with some fancy new algorithm, just remember that good ol' design pattern clichés are good.

What do you think? Is programming creative?