The Code Whisperer

In this post I’ve thought about some of the non-technical aspects outside of the normal development flow that support good software development. Their adoption doesn’t guarantee a successful software product, but they do help.

1. Solves a problem the user of the software has, whether it’s maintaining a list of their DVD collection or processing the accounts of an international company.
2. The user doesn’t have to substantially alter their process to accommodate the software. There is a limit, however. If the process the user is following is substantially flawed then I wouldn’t expect the software to be that flexible. Sometimes for simplicity the software has to impress a process on the user otherwise it offers too much choice - a bit like trying to choose a toothbrush. Any application has to tread this fine line between too much flexibility and being too rigid. I believe as software designers we need to assess that flexibility make a decision and ensure all potential users of the application are aware of this. As a result your application may not appeal to as many people, but those it does will be much happier with it.
3. The software is designed for real users, not all and sundry so has the features required to perform a task, not what the software designer thinks might possibly be useful.
4. The software designers and the development team understand and are passionate about the business and process that the software is aimed at. This is really important and is often overlooked. If the designers and developers don’t have knowledge of the business, there is likelihood that the software will miss the real needs of the user, and will offer a raft of functionality that is of little or no use to the vast majority of users of the software. Word processing software is a case in point. Most people want to just type and be able to format what they type. I agree features like mail merge and style sheets are very useful, but why would anyone want software to AutoSummarize a document they have been working on? If the company developing the software are actually users of the applications they produce, they will know what works and what doesn’t and, most importantly, the functionality required to get the job done as efficiently as possible. To help this get the development out of the office and into the environment their software supports. Don’t look at it as a day wasted, it’s a day invested as the experience will substantially boost their knowledge of the business.
5. Usability studies. There’s only one way to really evaluate software and that’s to watch people use it, either visually or electronically. Don’t rely on what people say they do, rely on what they actually do - it could well be different. Early prototypes, which won’t have the full functionality behind the scenes, are a good way of testing new applications or functionality. If possible use recording software on the computer or a video camera. Using a video camera also allows the user to be interviewed as they go along, crucial if they get stuck as it gives an insight into their thought process. It never ceases to amaze me the different ways people use software to achieve the same result. We released a beta version of Restoration Manager (link) for a cover CD-ROM on Practical Classics magazine. When the software started for the first time, it asked the user to specify some preferences, one of which was date format. This was achieved by a combo box with a handful of different formats to satisfy the European and US markets. However, despite the fact I knew you had to choose a date from the list, and every time I tested this part of the application I did this, the readers of Practical Classics had other ideas and decided to type in a date format, which caused the application to fail, but with a nice message box giving you the option of emailing the failure direct to us. Over the first weekend that the magazine was on sale, hundreds of potential users did just that. Quite frankly I was distraught, the biggest promotion the application would have and it fell at the first fence. We quickly produced an update and set up an autoresponder so anyone reporting the problem would instantly have a solution. On the bright side, however, it did prove the software was being used and we still get the occasional error report from the magazine CD-ROM 2 years after it appeared in the newsagents.

It’s often said that people don’t know what they want until they see something, then they realise they don’t want that.

If it’s a software development project then finding this out at user acceptance testing is far too late in the development cycle. Enter the prototype. A survey in Rapid Prototyping and Software Quality: Lessons from Industry by V. Scott Gordon and James M. Bieman carried out in 1991 revealed that prototyping can lead to better designs, better matches with user needs and improved maintainability.

Accordion Hero started as this prototype

If you’ve not come across prototypes before, they are a cheap, hacked, dirty (in terms of not worrying about coding standards) and disposable representation of what how the software will look and what it will do. The prototype is not a full working system - it can be a series of screens without any functionality, or can mimic some functionality with hard coded values. For example a list could be populated values, but these would be hard coded not derived from the database.

The First Golden Rule of Prototypes

Don’t use the same code for the real development of the application

Why? It introduces potentially poor quality code into your application. I’ve seen it many times, and six or seven years on, some poor developer new to the company and application is really struggling to understand code simply because it was prototype code and didn’t confirm to the standards. In addition it may be inefficient and just plain ugly and inadvertently may form the standard for the application.

The Second Golden Rule of Prototypes

Don’t make it look too good

Why? People that don’t develop software generally have no idea what goes on behind the scenes to make an application work in the same way I have no idea how a car is manufactured. In the same way I can see a concept car at a motor show and expect to be able to buy it from the dealer the next day, users of a system see screens and expect the application to be up and running in no time at all. The more perfect the prototype looks and behaves, the greater this expectation.

One of the first website I developed was for the local primary school. I took along a design containing a section of text from their prospectus. The aim of the meeting was to agree on a design, but having understandable text diverted their attention away from the layout. Interestingly the school picked up on several grammatical errors in the text and were horrified when the source was revealed.

The Third Golden Rule of Prototypes

Be aware of feature-creep

Feature-creep is the blight of any software development project and can be added by the development team or users. One of the dangers of prototyping is that the users and development team start to think more about the application and the surrounding processes. This can lead to features being added that have little benefit, sometimes at great cost. When additional features are requested look at the cost-benefit of adding the feature - there’s little point in spending four weeks developing a function that saves one person 10 minutes a year, unless there’s a substantial risk if the work carried out in the 10 minutes goes badly wrong!

If I sound negative about prototypes that really isn’t the case. I believe it is a beneficial tool that can lead to a much better application, provided it’s managed correctly and the three golden rules are followed.

Free Windows search tool Agent Ransack in action

If, like me, you’ve been frustrated with Windows search not handling all file types then take a look at the oddly named Agent Ransack.

In addition to simple searching, Agent Ransack can search using regular expressions, making it substantially more powerful than the Windows standard search.

A highly recommended addition to your developer’s toolkit.

In order to evaluate anything, from a sponge cake to a Bugatti Veyron there needs to be a purpose for the evaluation and a frame of reference. Evaluating a cake on taste or a car on styling is very subjective and only of value in larger numbers. Evaluating on size or speed is objective and the information easily understood and acted upon.

Measurement is the cornerstone of successful marketing, with a constant repeating cycle of try - measure - adjust, covering all media from Google AdWords to television advertising. There are a number of techniques such as A/B split and multivariate testing that can be performed on a website to maximise it’s potential. Measuring a direct marketing campaign or an ecommerce website is straightforward - number of responses and number/value of sales.

With software development measurement can be rather more tricky. Just with marketing it’s important to measure the effect of change to the development process if you use a new tool or amend a process it’s vital to establish whether it is a valuable addition or not.

Steve McConnell in his excellent Code Complete book discusses various metrics that could be used to measure software development. He makes the observation that Any way of measuring the process is superior to not measuring at all. I don’t completely agree. Introducing metrics into a development process that didn’t have metrics before is a good thing, but must relate to the measurement of something tangible so as not to lead to misunderstanding. It’s very easy to give a developer a hard time because he’s producing half the number of lines of code a day as someone else, but if those lines contain less bugs or the code is more complex the comparison is unjust. Let’s look at the Bugatti Veyron again. It’s a very, very quick car with a top speed of 253 miles per hour. At full throttle it covers 2.46 miles per gallon of petrol, emptying the 21 gallon petrol tank in under 13 minutes. As we’re restricted to a more leisurely 70 mph in the UK, with a combined fuel economy of 11 mpg, to cover 600 miles the Veyron would have to fill up twice, adding 15-20 minutes to the journey. My Peugeot 306 diesel returned 50 mpg and could cover 650 miles on its 13 gallon tank so on our 600 mile journey would be 15-20 minutes quicker. So purely on speed the Veyron easily wins, on fuel economy a clear loser and loses on our contrived journey time.

Now I’ve skewed these metrics, and that’s really the point. Speed and fuel consumption absolute metric, no subjectivity yet a 10 year old Peugeot is quicker than an £810,000 supercar, because of the legal speed limit and ignoring the small matter of acceleration and braking.

Back to our development metrics, I believe it’s essential to choose metrics with care so they don’t become misleading and give the wrong impression. Consider what you are trying to prove or disprove before making a final decision. Using total number of lines of code written over time might be the perfect metric for evaluating an IDE tool, but make sure the two projects compared are of a similar complexity, as a mate of mine says, compare apples with apples, not apples with pears. Also consider using more than one metric to measure, just as you are unlikely to choose a car on one statistic. Choosing the Veyron for a car to commute would clearly be wrong as journey time and fuel economy are important, and the 306 isn’t the best choice for a track car as top speed is important.

Steve McConnell lists a number of metrics in Code Complete, here’s the list boiled down a bit:

• Lines of code
• Work hours spent
• Number of times routine changed
• Cost
• Defect location
• Defect severity
• Defect originator
• Number of lines affected by a defect
• Time to correct a defect
• Number of attempts to fix a defect
• New defects resulting from corrected code

Don’t forget you can combine these to produce, say, number of defects per thousand lines of code.

Additionally Steve lists metrics aimed at measuring maintainability. These are:

• Number of parameters passed to each routine
• Number of local variables used by each routine
• Number of routines called by each routine
• Number of decision points in each routine
• Control flow complexity in each routine
• Number of lines of code in each routine
• Number of lines of comments in each routine
• Number of blank lines in each routine
• Number of data declarations in each routine
• Number of gotos in each routine
• Number of input/output statements in each routine

In a future blog I’ll look at how some of these metrics can be applied and delve into the maintainability metrics in detail.

One of the things that always bugs me is a lack of information needed to get a job done, be it the location of the source control system of whether you just help yourself to the hotel’s breakfast or wait to be seated and served.

With software development it’s often the case that an important piece of information is known or noted by a couple of people and everyone else asks. Worse still if only one person knows, and they are away the day that information is crucial.

Fortunately it’s easy to set up and maintain a Wiki. For those who haven’t come across a Wiki, it’s basically a web based tool promoting the sharing of information between people. Because public Wikis such as MediaWiki. This uses PHP and MySQL and will run on either a Windows or Linux server. Setting up will take a couple of hours and it’s flexible enough to adapt as you add new information. Make sure your team use it as the first port of call and if the information required isn’t there, it needs to be added, either by the person looking for the information, or, if applicable, the person with the information.

Be careful what information is added though. One Wiki I set up for a development company had been expanded to include To-Do lists in addition to various project planning and time capturing systems, which I think is a poor use of this facility. Also avoid duplicating information. We talked about coding standards a few postings ago, which should be a document. I wouldn’t expect to see the standards duplicated on a Wiki, however having a link to the standards document is a good thing.