Blogging from WordPress on iPod-Touch

I was browsing through the appstore and just found wordpress. The iPhone/iPod touch client for wordpress. So, here is my blogging experience from iPod touch! Installation was quick as with other apps. Here how the main page looks like Setting blog is just as simple as it should be. Just 3 fields to get going! After that, you are all [...]

3 major annoyances in Windows Mobile Device Center..

If you have not migrated yet to Vista, Here’s one more reason to defer By now, everyone knows, that in Vista, ActiveSync have been downgraded to Windows Media Device Center. Here’s top 3 annoyances in using that. Can’t Backup / Restore anymore Windows Mobile Device Center troubleshooting guide clearly states, backup and restore device data feature is only available [...]

Writing a System Test Plan

Using a test plan to ensure your software really works.

"Extraordinary quality doesn't make good short-term economic sense."
- Peopleware, Tom Demarco

Imagine for a moment you’ve just finished a web application for a client. Swimming around within that application is 100 bugs. What proportion of those bugs would you say is acceptable for the client to find (e.g. 50, 30, 10)? The point is, those bugs are going to be found by someone, and its either going to be you or the client. You can think of it as a sliding scale, the more bugs the client finds, the more your creditability suffers and the more damage you do to the business relationship.

In the martial arts there’s a saying; “expect the best, but prepare for the worst”. The US Navy Seals have a slightly more gun-ho version which goes; “The more you sweat in training, the less you bleed in battle.” Notice how it says the ‘less’ you bleed in battle, implying that if you enter into combat, you are going to get bloody. Software development is like this too, if you’re going to create software, you are going to get bugs.

As a rough guide, you want to try catch at least 80% of all bugs. Ideally, you would go for 100%, a worthwhile but lofty goal. Your best bet for catching as many bugs as possible is to create a system test plan. Creating a decent system test plan is easier said then done. A good place to start is your functional specification (assuming you have one). In effect, your specification gets converted into the system test plan. What you are doing is checking to see if the things you said you were going to do have actually been done.

A test plan is nothing new, in fact, the structure I use was developed by Microsoft years ago. It’s a simple format, a test case has a title, some steps, and an expected result.



I write my test plans with the intent of having an independent QA tester run through it, so no prior knowledge of the system should be assumed. You want someone who has never used the system before because they will take a fresh approach. You’re counting on them to use it in a manner which was never intended (e.g. on the ‘My Profile’ page, they type in a really long name for the ‘Company’ field and crash the system because the database only has room for a 32 character string).



You should keep your test cases short, to the point, and self contained (i.e. they generally don’t link to other test cases). If you have a test case that goes over a page, consider breaking it into smaller units. The document itself should be self contained as well, that is; it shouldn’t require the QA tester to get up and ask programmers questions like “what’s the login password?”. Instruct your QA tester to log any bugs they find in your bug tracking system and also to write a proper description rather then just saying “Test Case 16 failed.” You may want to read my article on Logging Bugs Like a Pro for some suggestions on good bug logging practices.

Article reviewed by Alex Barclay.

How the Web Was Won

Perspectives on how business has shaped the Internet.

Before you stands a frontier of possibilities, a land which at first seems desolate. Predictably, a tumble-weed rolls by, but in the distance you spy something looming on the horizon. Upon closer inspection it dawns upon you that what you’re gazing at is in fact ‘Big Business’. What had appeared to be ‘virgin soil’ at first glance, is in fact a well established arena â€" is it too late? Is there no room on the web for new comers?



There was a time when the web was a novelty, but these days, no one’s impressed if you say “I got the Internet at home”. As many people know, the Internet and World Wide Web were originally conceptualised and developed for military and educational applications. The war-mongers thought to themselves “great guns! A communication system that wont go down when the nukes hit!” whilst the university boffins exclaimed “neat, now I can share my research paper on the mating habits of cockroaches with professor Irvine at Oxford!”.

If information sharing spawned the web, how is it that business is now such a dominant aspect of cyberspace? Obviously, at some point, an entrepreneurial-type thought to themselves “hang-on, what if we used this ‘Internet’ thing to sell stuff?” Now, this may have seemed like a fantastic idea on paper, but at the time this idea was conceived, the web was hardly in state to support such rich functionality (not easily at least).

So why is it that online shopping has become so pervasive? If you take a look at juggernauts like Amazon.com and eBay, it would seem like their triumph was almost pre-destined. But lets not forget follies such as Egghead.com and GovWorks (of ‘Startup.com’ movie fame). And you wouldn’t know it by looking, but there was a time when Yahoo.com was in serious trouble too. For every success, countless others must have fallen by the wayside.

The dot.com bust will certainly go down in web annals as a dark time. If you’re not familiar with why it happened, this is an example of the sort of thing which went on; web company A would buy $10m of advertising from web company B, web company B in return would purchase $10m worth of advertising from web company A. This would make it look as though each of the companies was massively profitable â€" but like all shoddily constructed pyramids, it all came crushing down in the end.

If the road was fraught with so much peril, then what made companies invest so much capital in ecommerce? There are a number of factors which make the web such a pliable tool for selling goods and services online. For one, an online shop is always open, a world of people can buy from you (literally), it doesn’t have rude staff, it’s cheaper then an actual shop-front (and the ‘rent’ is next to nothing), it can potentially deal with thousands of customers at once, and the list goes on.

So how has business shaped the web? Would it be too extreme to say that business is the web - perhaps, but it sounds deep upon first reading. It could be argued that commercial use of the Internet has brought it to where it is today because it facilitated advances in technological infrastructure (eg. up-take of broadband, establishment of high-speed international fibre-optic backbones, etc), but it’s not really necessary to get quite so ‘fancy’. At the end of the day, people noticed that there was a need that had to be filled, they also noticed a tool that could help satisfy that need. At this very moment, chances are you have a need which is being fulfilled by the Web.

User Acceptance Testing

A formal process for demonstrating project completeness

Ever had a project where you thought you were done, but the client had other ideas? The project schedule may say all tasks are done, the QA tester may have successfully run through the System Test Plan, and the programmers may have cleared all known bugs. So why wont the client settle their account and let you get on with your next project? Easy, they don't know the project's finished, and why should they unless you can demonstrate without a doubt that you have delivered on everything you promised.

This is where User Acceptance Testing, or UAT comes to the rescue (also known as System Acceptance). It's not quite the finale of a project, but its getting close. You could say the Sign-off Agreement or Project Post-mortem is the real project end point. In essence, System Acceptance helps give closure to a project, without it, you may have a tough time convincing a client to sign the Sign-off Agreement (where the client formally indicates they are happy with the work you have done).

The actual structure of the document I use for System Acceptance is quite simple, filling it in is the tricky part.



The idea behind the System Acceptance process is to first make a list of every screen contained in the system, then you arrange a time to go sit with the client and systematically go through all the screens with them. For each screen, you ask the client two questions; 1) does the page appear error free?, and 2) does it perform all functions according to the spec? If the screen passes these criteria, its initialled by both you and the client. If you're thinking "oh god, doesn't that get really tedious after about twenty screens?", you are absolutely right. But as painful as it is, it will produce the desired effect; a tangible sense of closure within the client's mind. I recommend you forewarn the client of the less joyful aspects of the process, explaining that there will likely be multiple sessions lasting a few hours each, and that the process may seem inane at times, but you ask that they bare with you.

Now for some inconvenient truths. Will you complete the acceptance process in the first session you book with your client? probably not. As a rough guide, allow ten minutes per screen, a twenty page web application could take over three and a half hours. However, what tends to happen is the client really starts thinking about their software once they realize its almost over, its their last chance to make changes before they become indisputable feature additions. The result is that you may get side-tracked. The other issue is that a UAT session isn't meant to be a critique of interface cosmetics or functionality, but it can easily turn into such a discussion.



If the time consuming and tedious nature of UAT weren't daunting enough, there is another looming danger; bugs. Chances are good the client will discover bugs during the acceptance session. If you've been wondering what the 'Comments/Notes' column was for, now you know; to write down bug details. What will probably happen is a good portion of the screens will pass, and some wont. You will have to make arrangements for another session with the client after you've had time to get the bugs fixed. Eventually you'll have all screens signed off, then you are ready to present the client with the Sign-off Agreement.

Logging Bugs Like a Pro

Tips and hints for reporting bugs more effectively.

This article serves as a brief guide on best practices when it comes to reporting bugs. Encouraging QA testers, clients, and other project stake-holders to follow these habits makes life easier for the development team when it comes to tracking down and fixing a bug. The end result is less time wasted in going back-and-forth finding out the details of a bug. The act of submitting a bug in a formalised way is very important â€" having a record of the bug means it wont get lost or go away. The other benefit is someone has clearly taken responsibility for dealing with the problem (i.e. a bug should be assigned to a person).



When submitting a bug, it’s a good idea to give it a short, descriptive title. It may seem like a chore, but it assists developers to quickly identify what a bug is when looking at a list of bug titles. It also helps in future when trying to recall what an old bug was about.

To create a good title, all you need to do is think to yourself “what exactly is the problem?” The first thing that pops into your mind is usually a good title. Examples of good bug titles would be: ‘my login details aren’t being saved’, ‘the photo gallery page crashes in IE’, or ‘tax totals on invoice report are not accurate’. Some examples of unhelpful titles would be: ‘error on page’, ‘the system is busted', or ‘the system doesn’t work when I use it’. A good bug title may also include what screen the error occurs on and describe only one problem at a time (e.g. “sign-up page crashes when I enter a long username”).

Probably the most important aspect of a helpful bug report is to give the steps required to reproduce the problem. All you need to do is give a step-by-step account of what you were doing when the bug appeared.

For example;

* Login as a standard user
* Go to ‘My Profile’
* In the ‘Surname’ field, enter O’Brien
* Click the ‘Save’ button.

You’ll see the page has a script error and doesn’t save the surname.

Example of an unhelpful bug report;

There’s something wrong with the profile page. It crashes, my computer reboots, and the cat goes and scratches the couch.

A few simple habits can enhance a bug submission significantly. For instance; using asterisks as bullets, giving just enough detail to be able to recreate the bug (one line is unlikely to help, a novella adds little benefit), and, at the end of the steps, say what went wrong (e.g. “the page has an error”, “data goes missing”).

When logging a bug, a priority rating is often assigned to it. Most bug tracking systems have choices like low, normal, or high. A low priority bug would be something which just looks bad (e.g. a spelling mistake, misaligned controls, etc). A high priority bug would be a page crash, data corruption, or vanishing data. All other bugs would fall into the category of normal. An accurate priority rating is worthwhile since it allows more pressing bugs to be fielded first (e.g. it would be more important to fix a broken login page before a UI issue).



Occasionally, a situation may occur where it’s hard to tell if something really is a bug, it may instead best be categorised as a ‘feature addition’. As a general rule of thumb, its a bug if; a script error occurs, data goes missing or is corrupted, the system behaves in a manner in which it was not intended too (i.e. not to spec).

'Maintenance Blocks' - Managing Change Requests

An equitable system for maintaining and upgrading client work after launch.

What Are ‘Maintenance Blocks’? It’s an idea I developed which is meant to provide a fair system for undertaking bug fixes or upgrades on client work. In simple terms; they are pre-paid units of maintenance.

It never felt quite right to round-up 15 minutes of work to one hour (for the purpose of creating an invoice). However, I wasn’t happy about doing work for free for a client just because it was a small task (e.g. creating a new email account, adding Google Analytics to a website, etc).

One of the major advantages of maintenance blocks for clients is that a lower rate is locked-in for future work. There is also a degree of convenience since invoices aren’t being sent out for small pieces of work. In addition, maintenance blocks are very flexible since they can be used for either bug fixes or upgrades to a client’s existing project.

Maintenance blocks are also about mutual obligation. Having a client pre-pay for maintenance work ahead of time is a sign of good faith. In return, I give a guarantee on turn-around time (generally 48 hours from the time the request is acknowledged). If I don’t respond within the agreed amount of time, the client gets their work done for free.

I designed maintenance blocks to be purchased in ‘packs’, generally eight or sixteen blocks, with each block being equivalent to 15 minutes of work. Depending on the complexity of the task (be it an upgrade or bug fix), varying amounts of blocks are consumed. Generally speaking, a minor change would use 1 block, an intermediate change would consume 2-3 blocks, and a major change will use 4 or more blocks (nb. minor or intermediate changes are most common).



I generally have it so blocks do expire, but the amount of time they stay valid is quite long (e.g. 6 months for eight blocks).

The way a client uses maintenance blocks is quite simple. They would email a request for change via email, I then let the client know how many blocks need to be used for the change and how many maintenance blocks they will have left after the change (e.g. “you have 3 maintenance blocks remaining, the change you are requesting will use 2 of those blocks - leaving you with 1 block”). The client then confirms their agreement or raises any questions they may have.

The system is squarely aimed at small bug fixes or changes. For example; “the positioning of the logo on my website looks funny in Google’s new browser, can you fix it?” or “please add a new menu item and page to my website called 'Customer Feedback'.” The system is not meant to cover major changes (e.g. adding online shopping facilities, re-vamping the layout of a website, etc). Generally, if a change is more then 16 blocks in size (i.e. more then 4 hours), I consider it to be beyond the scope of the maintenance blocks system, and therefore would require a separate contract to be negotiated.



Why do maintenance blocks get used for bug fixes you may ask? When a project is still under ‘software warranty’ (typically, for a period of 6 months after completion), blocks don’t get consumed for bug fixes. But after the warranty period has expired, I do charge clients for fixes on their projects even if they are my fault. With the work I do, most bugs are found during the QA cycle, with few emerging past the 6 month point (but it still can happen).

Lastly, I don’t ‘force’ clients to use the maintenance block system if they don’t want to. The alternative is to negotiate a charge-out-rate and turn-around time whenever work needs to be done. At it’s core, the system was created to make everyones' life easier. Costs are settled before-hand, thus allowing us to get on with what’s important; the work.

A Basic Document Storage Structure

A simple folder structure for storing project documents and support files

Last time I proposed this directory structure I was tortured, put onto a rocket and launched into the Sun (I survived, a little crispy, but alive).

Why is the folder structure I use so radical? Probably because it looks too simplistic to work. But I assure you, I have been using this structure for years now with great success (even on large projects).

Now, without further ado, here is the folder structure:



Hard to believe, but that’s all that’s really needed. The simplicity is driven by two factors; one, you can’t find anything anyway when you use a convoluted/deep directory structure, and secondly, its habits which make this approach work.

I can see some of you gesturing to the head-torturer, indicating your desire to use the iron maiden, but bare with me whilst I explain.

One question which may come to mind is do you name the top level folder after the client or do you name it after the project? The temptation, and I have seen this done, is to create a structure like this: Client Name->Project Name. For example; you would have the folder Acme, and under that you would have Blue Widgets and Hyper Widgets (nb. these would be two different projects belonging to the client called Acme).



A consistent hierarchical structure like this makes sense doesn’t it? Well, it does if you want to place the information you constantly need to access an extra click away. So which is it? Most of the time I use the client’s name. The reality is most clients will only have one project done with you, perhaps with maintenance being carried out on it in future. Flat structure is what it’s all about.

(Archive) - I have a ‘never delete’ policy. To a certain extent, it’s more about me not wanting to waste time trying to figure out if something should or should not be deleted. Back in 1993 when I had a 106 megabyte hard drive, storage capacity was an issue, it isn’t any more. The (Archive) folder is the key to making the folder structure work. Old versions of documents and support files get dumped here, this prevents the Documents and Media Dev folders from getting cluttered. As a general rule; if in doubt, back it up.

Documents - funnily enough, this is where your Word documents go. You put any kind of support documentation in here, be it PDFs, an Excel spreadsheet, or a Visio wireframe. I generally set the folder to show the most recently modified files first. You tend to work with the most recently created files the majority of the time. It’s important to move super-seeded documents into the (Archive) directory, otherwise the Documents folder can become unwieldy, especially on big projects.

Media Dev - this contains any imagery or multimedia content related to the project (e.g. logos, Photoshop files, Flash animations, videos, etc).

“Yeah, but the project has millions of documents” I hear you say. True, it does happen. But that’s what F3/Search was designed for. You are going to need to find older documents by keyword anyway. Plus there’s nothing wrong with having sub-folders if you really feel the need (e.g. AcmeDocumentsUser Manual).



At the end of the day, its pretty easy to decide which folder things go into, your files are either going to be a document of some sort, or a image/video. A quick note on file naming. Your company probably already has a system of some form, the only thing which I have to offer is recommending that you append a revision number on the end of documents. For example, spec_acme_rev_02.doc as opposed to just plain old spec_acme.doc. You may already have the revision number contained inside the document, but a person would have to open up the file in order to see it.

Creating an e-Strategy

How a website can boost traditional marketing techniques

What is an e-strategy? Good question, I have to admit it is a rather vague notion. One way to describe it is to say that it’s about mixing technology with traditional marketing strategies. As these approaches interconnect, they compliment or magnify each other, thus producing an affect where the whole is greater than the sum of it’s parts.

In more specific terms, an e-strategy is the business strategy applied to an online presence. It generally does not focus on technology comparisons, but rather is geared towards presenting the best possible approach for achieving an organisation’s goals.

Why would a business want to develop an e-strategy? The main reason is because it’s a game plan for how to get the most out of their web presence. The idea is to exploit the Internet and emergent technologies in order to increase revenue or reduce operating costs. A common way of reducing costs would be by automating as many activities as possible. For example; an online book store which does just-in-time printing could send an automatic communiqué directly to the printing company when a book is purchased (the book would then be printed and mailed off to the buyer).

Part of an e-strategy is to make it clear that good technology in itself is not enough, a holistic approach is what is needed. Traditional business techniques also need to be used in order to produce growth and out-do competitors.

As part of this process, a few key questions need to be answered; what role can the Internet play in the business strategy? What is the driving force behind the business? How are customer or target market needs fulfilled? What does the future hold for the business domain and how is change going to be handled?

There are many ways that the Internet can help a business. The examples I have here are by no means an exhaustive list, I’m sure some lateral (creative) thinking would reveal even more options.

Demand Aggregation â€" as the size of a company’s patronage grows, so to does its ability to secure a good deal for its customers via buying power (e.g. a driving range could buy golf balls in bulk to sell to club members at a better then retail price).

Producer Direct â€" a business which sells products online can bypass the cost of having a physical store-front. This allows them to pass on savings or ‘perceived value’ to customers (e.g. eBay or Amazon).

Product Re-bundling â€" having a multitude of customers that grow in an organic manner opens up the potential for related but separate products or services to be offered in combination. This would not normally be possible on a stand-alone basis (e.g. a gym could approach a sports store and strike-up a synergy where-by gym members received discounts on sporting goods).

Customer Self-service â€" technology can be used to reduce the amount of time staff spend directly interacting with customers for simple tasks or enquiries. A classic example of this is a customer researching a product online rather then phoning a store to ask a shop assistant about the item.

One-to-one Marketing â€" this strategy emphasises personalising interactions with customers. Having a customer’s full name at the top of an email is a simple implementation of this approach. This increases the likelihood of them actually looking at the email rather then discarding it as junk mail. A more effective usage would be a website where customer demographic information such as age is tracked. This could then be used to target promotional advertising more effectively (e.g. there’s no point showing home loan packages to teenagers).

Channel Integration - this is about having a number of different ways to communicate with your customer or fulfil their needs (e.g. phone, product brochures, direct mail, physical store-fronts, etc). A popular implementation of this approach on websites is to ask a person if they want to receive promotional material via email during a sign-up process.

An e-strategy needs to explain how technology can serve a business’ goals (e.g. to have products on supermarket shelves by the end of the year, to raise skin cancer awareness, etc). This is done by determining how business objectives can be linked to an Internet-based solution such as a website.

Without an e-strategy, technology-based solutions developed reactively may produce short-term benefits, but turn-out to be ineffective and expensive in the long run. For example; if you wanted to develop a mobile-device interface for a social networking website, you could produce BlackBerry and MS Windows Mobile applications, or you could try and capture a far greater audience by targeting just the Symbian OS considering it’s installed on 72% of all smart-phones (Source: www.itwire.com/content/view/14348/127/).

Management Styles in Web Development

How operations management affects project management in a web development environment

“Fostering an atmosphere that doesn't allow for error simply makes people defensive. They don't try things that may turn out badly."
- Tom Demarco, Peopleware

One of the best teachers I know once let a martial arts student punch a wooden board when he knew it wasn’t going to break (due to incorrect technique). After the student’s failed attempt, he said to the group “I could tell it wasn’t going to break, but who am I to stand in the way of your dreams and goals?”

It’s happened a number of times now that I have arrived at a company and heard statements like “run projects how you think best. After all, we hired you for your expertise and experience.” These bold proclamations inevitably give way to operational management’s desire to change things for the better good (i.e. over-ride some of my decisions).

Perhaps this happens because project management looks like a logical pre-defined process, much like operational management. However, the whole point of a project is to create something novel and never before seen, thus introducing a large element of the unknown to the undertaking. This is one of the reasons why risk analysis is such a major part of formalized project management methodologies.

Passion or concern can often lead operational management to actions which actually stifle a project. Much like a mother, at some point they have to ‘cut the apron strings’ and allow their child to make some mistakes for themselves.

It’s like watching a child banging their toy against a wall, do you say “that’s going to break if you keep doing that” or do you take the toy and save it from certain annihilation, potentially robbing them of a valuable lesson on taking care of their property? On the other hand, some lessons can’t be learnt the hard way, for example; crossing the road without looking both ways.

The question then becomes, do you stand by and watch someone make a mistake? I would hazard that this would often be the motivation of upper management, that to them it looks like you are about to make a mistake which could cost the company money or damage client relations, so isn’t it logical to intervene before its too late?

I’m fairly sure no managing director wakes up in the morning and thinks to themselves “hmm, how can I make my project manager’s life difficult today?” I should say that I don’t intend for this article to be a denigration of past employers. Operations managers generally don’t acquire their position without being highly intelligent and capable. But I have seen the phenomena Joel Spolsky calls Command and Conquer Management. This is where the person least qualified to make a decision is doing just that.

From the companies I have worked at so far, I have seen three distinct approaches when it comes to operational management dabbling in project management. One type would commonly interject if they felt they had a better way to do things (with changes I could not veto), another would occasionally come to the rescue if things weren’t going as planned (again, with me having no veto power), and probably the most interesting one has been a boss who only occasionally intervened, but still allowed me to have final say.



Personally, I wouldn’t want to work in an environment where people didn’t say something if they felt you were about to make a serious error with your work. But that is obviously part of what team is about. People need to be able to ask questions and give suggestions. But they should also be given the option to reject a suggestion without ego coming into it.

Project management isn’t an easy discipline, hence why not everyone does it. As mentioned earlier, the reason for this is because a significant portion of a project is unique. Getting good at tackling the unique aspect of projects only comes with experience, and experience comes in two flavors: success and failure. Unfortunately, it’s hard for some people to accept the unpredictable nature of software development because mistakes can be expensive.

Another interesting ingredient being added to this dynamic is the increasing uptake of industry standard project methodologies such as Britain’s PRINCE2. Although this is definitely a good direction for the software industry, it does pose a potential hurdle.

PRINCE2 is squarely aimed at project managers, there’s no doubt about it. The problem lies in the fact that non-project managers within the team also need to understand the methodology for it to work well. I believe it’s possible for a project manager to teach the basics of PRINCE2 to subordinates such as team managers, programmers, designers, etc. (just enough for them to get by). But would this work upwards, with corporate management?

Sign-off Agreements

Getting closure on a project by using a sign-off document

A Sign-off Agreement is simply a document both client and technology supplier sign at the end of a project. In essence, it signifies that a client is happy with the work they have paid for.

You could say the Sign-off Agreement officially marks the end-point of a project, generally trailing behind UAT (also called System Acceptance). Could you close a project without a Sign-off Agreement? Of course, you may be thinking this process is overly bureaucratic, and that may be true for certain situations.

So, what's the point of the Sign-off Agreement? One reason behind it is to give everyone involved in the project a sense of closure. I would say this idea of closure is a good thing, for one it gives the development team a feeling of achievement. Another important aspect is it sets up a boundary relating to version control (i.e. version 1 is done). The concept of versions for web software is somewhat meaningless because of the ease with which updates can be delivered. However artificial, versions can be good for creating dividing lines between a delivered software package, and its next batch of features.

Probably the best answer on whether you should use a Sign-off Agreement on your project is 'maybe'. It comes down to a few key factors; the type of project you have, the kind of client you are working with, and the situation. For instance, if you are dealing with a government body then a certain degree of governance and process is to be expected. As often as possible, do try and use a Sign-off Agreement, but if you are in a situation where you need to concentrate more pressing tasks, then this process is a good candidate for culling.

An important aspect of the Sign-off Agreement is to make a statement about your Software Warranty. This is where you say how long you will be fixing bugs for free, and also what your definition of a bug is. Another way to think of this is as a rudimentary service level agreement (but without any commitments on turn-around time). Failing to discuss the idea of Software Warranty with your client leaves things open to interpretation and can setup the wrong expectations (e.g. a client may just assume you will be fixing bugs forever). How many months should you offer a warranty for? I don't know, that is really up to you. I have seen 3 months, 6 months, but I also know someone who basically fixes bugs for free no matter how long ago the software was delivered.



I like to keep the Sign-off Agreement to one page since I believe people have better things to do with their time then read long documents. I start with my Document Purpose section so someone picking up the sheet of paper can understand what it is about within a few seconds. The format of Sign-off Agreement I use is not designed to be water-tight from a legal perspective, that is not its purpose.

Towards the start of the document, I have a block called Agreement Parties, this just makes it clear who the client is and who the technology supplier is. The statement about the Software Warranty follows soon after.

The bulk of the document is the Terms section. The main point here is to say that your company has fulfilled all its contractual obligations and that the client is happy with what you have produced for them.

Something you may wish to discuss in the document is a maintenance rate for feature additions post-launch (also putting a time limitation on this quoted rate). I will probably be moving away from this style of agreement in favour of more flexible system involving Maintenance Blocks, but this is a discussion for future, after I have had a chance to road test the concept.



The last part of the document is an area for one of your company representatives to sign and date, and an area for the client to do the same (it is called a sign-off agreement after all).

A good tip for using a Sign-off Agreement is to give your client plenty of notice before presenting them with the document. It looks kind of legal, so it may make a client feel as though they are being backed into a corner and are about to relinquish control over their project. It’s important to explain what it is early on, for instance, just before or after UAT.

Reviewed by Patras Surna. Rev. 02.

Wireframes and Mockups - Part I

Lo-Fi techniques for creating effective UI wireframes.

Part 1 focuses on lo-fi approaches such as pen and paper-based techniques. Part 2 is concerned with more refined tools for producing polished UI mockups.

UI mockups, or wireframes, are a major part of any respectable functional specification. A functional specification is a description of how the software will work from the user’s point of view. This article doesn’t cover the reasons why you need a functional specification, for this I would suggest Joel Spolsky’s article Painless Functional Specifications. The focus of this piece is to describe and analyse a few approaches for creating UI mockups.

I’m sure there are many other approaches for creating wireframes, but I can only describe and comment on the ones I have used, making some general statements on what is good (or bad) about them.

Lo-Fi Prototyping â€" this is just the fancy name for the old butcher’s paper approach. Hands down, its the best technique when a new shrink-wrapped software package is being designed. It really lends itself to collaborative effort, it gets the creative juices flowing, and the speed at which you can produce rough screens is unbeatable.



I once spent four days with a group of developers in a small apartment designing a telecommunications application using this technique. The result was just short of astounding, it allowed us to blast out and iterate ideas very quickly. As the UI designer for the team, I went home at the end of the week with a mass of paper which I turned into over 30 HTML mockups.

This approach is unsuitable for designing simple business websites or software which has been done before (e.g. non-novel systems like a shopping cart). It’s also not so great when a client is directly involved in the project. There are a few reasons for this; it requires a big investment of time on the client’s behalf (they may have a business to run during the day), and secondly; the client-to-supplier relationship often creates a dynamic where they tell you what they want, and you go off and make it. Normally, the client wont hang around whilst you design their software.

Microsoft Excel â€" yes, as strange as it may sound, MS Excel can be quite handy for producing wireframes, especially for software which is expected to have long vertically scrolling screens. I would never have thought to use it myself, but a company I worked for introduced me to it as their preferred spec’ing tool.



At first I was skeptical, but I quickly warmed to the approach when I saw how fast screens were to make once I got the hang of it. It’s excellent for inserting instructions to programmers (either in comments or as side-bar text). It does however produce exceedingly ugly wireframes; this is a good thing for application design since it keeps everyone’s focus on usability and business logic.

The other great thing about Excel is everyone is familiar with it, including clients. The closest thing I could think of as a criticism of Excel as a wireframe tool is that it produces decidedly uninspiring visuals. I currently don’t use Excel as a wireframe tool, but I would have no problem picking it up again if I felt it was right for a project.

Microsoft Word - another desktop application you wouldn't normally think of as a wireframe tool, Word can be pretty good in certain situations. Generally, the only time I would use Word to represent UI controls is if I am making a ‘mini-spec’ for a web-based application.



A mini-spec is created in one of two situations; as an adjunct to an already ratified functional specification, or as a mechanism for grouping together a bunch of features for a version upgrade. UI controls are represented in a very rudimentary fashion, for instance; (*) would be a radio button, and [x] would be a checkbox, etc.

This works because the interface for the system has already been established (i.e. the system has been coded or a Photoshop mock-up exists). The advantage of this approach is speed; you describe the underlying functionality of the code and only mock-up the controls relevant to the feature rather then drawing the entire screen.

Continue on to part 2 of this article to find out how Visio and Photoshop can be used to produce highly refined mockups.

Managers, Programmers, and Designers

How managers interact with technical staff to produce software.

“Those convinced against their will are of the same opinion still."
- Dale Carnegie

Depending on the structure of your organization, the project manager is most likely the person who interacts with the broadest range of stake-holders. Sure the managing director will intermingle with project managers, business development, maybe even the client at early stages. But a project manager will interact with all these people and more; most notably, technical staff such as programmers and graphic designers. And let’s not forget the client; a project manager will probably spend the largest amount of time with them compared to anyone else.

Every now-and-then someone comes along with a ground breaking theory or universal law that’s so simple its mind-blowing; Maslow’s Hierarchy of Needs, Covey's 7 Habits of Highly Effective People, and of course the three business personalities described in Michael Gerber’s classic book The E-Myth (i.e. entrepreneur, manager, and technician).

For those not familiar with the book, what follows is a brief summary of the personality types:

The entrepreneur's work is strategic in nature, involves focusing on the future and developing a vision of where they want to take the business.

The manager's work is both strategic and tactical. The manager's focus is on the present and achieving results through others. They are concept to reality facilitators.

The technician follows the guidance of the manager to get the work done. They focus on the present and are hands-on.

The E-Myth is about much more then just these personality types. It’s about the pitfalls of starting your own business, and how to build a business which allows you to live the kind of lifestyle you want.

We are all combinations of these characters to different degrees. Some of us are half manager half technician, others are very entrepreneurial, and so on. Understanding these archetypes can be very helpful when working in a team environment.

I am about to make some generalizations, and as with most generalizations they should be taken with a grain of salt since there are always exceptions. Programmers and designers commonly fit squarely into the role of technician, perhaps with a splash of manager (nb. by designer, I mean graphic designer).

There are a number of contrasts between programmers and designers, even though both are fundamentally creative disciplines. Perhaps this is because the work of a designer is visual and more apparent to users, whilst a programmer’s output is functional and more ‘under the hood’.

I interviewed a professional graphic designer to find out her thoughts on the interaction between managers and technical staff, here is what I found:

Q. “How do designers differ from programmers?”
A. “Programming is objective, design is subjective. Designers work with imagination [whilst programmers are more academic].”

Q. “How should a manager go about asking a designer to make changes to their work?”
A. “[Managers should refrain from] involving themselves in the design process. Changes need to make sense and be based on solid reasoning. [Berating comments should be avoided].”

Q. “How can a manager’s input be counter-productive to the design process?”
A. “There is nothing more frustrating then a manager trying to be a designer. [There needs to be] concrete reasoning behind the suggested correction.”

Q. “What are the most common issues between designers and managers?”
A. “When a manager shuts down creative flow by being too overbearing. [Micro-managing or meddling] is a common problem.”

Q. “Should a manager’s opinion on visual design hold less weight then a designer’s?”
A. “Unless working in a small business, [managers don’t] need to involve themselves in design. Opinions and feedback are always welcome, [but emotive recommendations should be kept to a minimum].”

Q. “Would it bother you if someone changed your work without asking you first?”
A. “[I would] not be happy. [Managers wouldn’t like their processes being bypassed without being consulted first].”

- Vera Babenko, Lead Web Designer, ANZ Bank.

Note: I have shortened or paraphrased the interviewee’s answers. The changes have been checked by the interviewee to ensure the original message has not been lost.

A pattern I have noticed with graphic designers which does not seem as prevalent in programmers is that it can be quite an upheaval to suggest a change, or even worse, to go ahead and make a change without their prior knowledge (a move rarely conducive to harmony within a team). Perhaps the reason this phenomenon is more prominent in designers is because artistic endeavour is so subjective; what looks good to one person may look uninspiring to another. When a programmer is asked to make a change in functionality, it generally has a tangible and visible affect, something people can agree on.



When working directly with designers, I will often make suggestions based on my strong usability background. Even though I have seen graphic designers violate well established best-practice usability guidelines (e.g. using ‘|’ as a breadcrumb hierarchy separator instead of ‘->’), I never insist on a change. What I generally say is something along these lines: “have you thought about changing this to this because...?” If they don’t want to change it, I don’t push the issue.

To me it’s beside the point whether I think I know better, the designer’s work is their dominion and their responsibility. The only time I would revisit the topic is if the client wasn’t happy with it, then I would come back to the designer and say “well, regardless of whether the change is right or wrong, the client wants it the way they want it”.

Project Schedules with Google Spreadsheets

Task tracking, estimation and distribution with Google spreadsheets.

Creating software without a project schedule is like driving a car without a seatbelt; it can be done, but that doesn’t mean it’s a good idea. Before we go any further, I should say that this article isn’t about why you should have a project schedule. If you need that kind of convincing, may I suggest a great article by Joel Spolsky called Painless Project Schedules. In fact, the style of project schedule I use is derived from his method.

What I would like to talk about is how Google spreadsheets can be a real treasure when it comes to making your project schedules. Like many tales, this one begins with a cause to be championed. Not so long ago, I worked at a company with three programmers. It was my job to make sure projects were delivered on time and to spec. Resources at this company were very tight. This meant that any time savings I could get by streamlining a process, I would go for.

In the past I had used either Microsoft Project or Microsoft Excel for scheduling. Putting my project schedules in Google spreadsheets offered a number of perks. For one, the schedule was accessible from anywhere anytime (home, office, mobile, etc). Another bonus was that multiple programmers could edit their relevant areas without any sharing issues. Also gone were concerns about backups and where on the company server the file should reside.



If you look at the structure of the project schedule I use, you may think to yourself “it’s so simplistic, surely that isn’t enough to cover a complex project?” But really, what more do you need? You write down what the task is, an estimate for how long it will take, who’s meant to be doing it, and how much of it has been done.

OK, you got me â€" this style of project schedule does have two major flaws. For starters, it’s hard to figure out delivery dates, another problem is that its tough carving out distinct milestone. But where this style or project schedule shines is in task management, you won’t miss things, and as the saying goes “the devil is in the detail”. It’s an excellent way for distributing tasks to team members. It also provides a very good overview of where you are at any given time within a project.

Personally, I tend to create my project schedules with only five phases (you can have more if you like). I’ve found all tasks will fit into one of these categories: wireframes/mockups, coding, project management, quality assurance, auxiliary tasks. Auxiliary tasks being the ‘catch-all’ for tasks which don’t neatly fit into any of the other categories.



I also like to create a ‘summary and charts’ page, but this is gilding the lily. I find that it's handy when my boss asks me “how is the Widgets project going?” I can answer “overall, its 92% done â€" we are on track”. Its also helpful knowing how many hours have been allocated to different team members. One reason I do this is because I have a bad habit of taking on too many technical tasks which really should be going to the production team (what can I say, I used to be a programmer).

Having a project schedule is great, but the unfortunate reality is that most people could care less about it. From my experience, upper management generally aren’t that interested in the detail of the schedule, but they do appreciate its existence. They will more often be interested in milestones and delivery dates.

The other hurdle is getting programmers to use the schedule. Most of the time I’ve found programmers aren’t too keen on directly participating in the maintenance of the schedule, but you must bring them into the fold. Programmers are far more interested in cutting code, which is good â€" it’s what they love to do and what they are there for. So how do you get your technical people involved in the project schedule? Basic people management skills really. People will be far more inclined to do something if you ask them to do it rather then order them to do it, and people are more inclined to do something if they are given some choice in the matter. To a lesser extend, that often vague concept of ‘ownership’ comes into play here.

What I often say to the programmers I am working with is something along these lines; “Tony, when you have time, can you please go into the project schedule and update your areas. Also, for the life of this project, I need you to go in at least once a week to update your areas”.



Over the years, I’ve found this approach works very well for a number of reasons; there is ‘choice’ in there; saying “when you have time” and “at least once a week” leaves some breathing room for people to manage themselves. People are always happier when they have options. The subtle wording; “your areas” connects to ownership. It means the project schedule belongs to them as well. Of course, never underestimate the power of manors - “thank you” and “please” always go a long way. There is a caveat with this approach however, it requires sincerity. People will spot it if you are saying something you don’t believe in.

Before I go, I would like to offer a few tips on how to construct your project schedule. When writing out the name of a task, be distinct, it should be some kind of action (e.g. “re-delegate domain name” is good, where as “undertake hosting tasks” is a little vague). Estimates for tasks should never be more then 16 hours (if they are, break it down into more tasks), but also avoid too many 0.25 hr blocks - that’s just going overboard. Do your best to fill in the ‘current estimates’ column, this can be used in future to highlight tasks you’ve underestimated.

Article reviewed by Sarah Hunt.

Writing Fee Proposals

How to write a fee proposal and knowing what to put in it.

Over the years I have seen a number of different styles used when it comes to writing fee proposals. Generally, the differences come down to personal taste; how much disclosure on costs do you give the client, how voluminous are your terms and conditions, should you put a portfolio of past work at the end of the document, and so on. My ideas on how to create a fee proposal are no more special then anyone else’s, but I have found they have worked well for me. I should say that this format of fee proposal is best suited to web development projects in the range of 40-120 hours in duration. So, you probably wont be winning that big government contract with this template.

With most of the documents I create, a big motivation is to go for maximum ‘bang for buck’ â€" no one likes reading long documents, so I’m not going to write more then I have to.

I like to start with a Document Purpose section, I do this in nearly all documents I create. If you look at it this way; you wrote the document, so you know exactly what it is, but when someone else picks it up, the first thing they will think is ‘what is this?’ The Document Purpose section can be something as simple as saying “the purpose of this document is to describe the tasks involved in creating The Blue Widgets shopping site. These tasks will then be used as the basis for producing a cost for the project”.



Next I like to have a section I call Purpose of the Website. This is a brief bullet point list of the business case for the website; what its trying to achieve in fairly concrete terms. For instance; ‘Let customers buy Widgets online’, ‘Give customers information about Widgets’, etc. These statements are big picture, they also demonstrate to the client what you think is important about their project. If there is misalignment of ideas, the sooner it comes out, the better.

Client Background is another block I like to put in. Nothing too long, just one paragraph to show the client I have been paying attention and have some basic understanding of what they do â€" I think this is important (e.g. “Blue Widgets has been manufacturing widgets for over 10 years and sells its products via a number of retail outlets across the country...”).

Another section which some people may or may not like is what I call Technology to be Used. You could say it’s irrelevant, but I like to set-out what programming language the system will be developed in and what database it will use. Probably the most important aspect of this section is technical limitations. And yes, you got it, this is an exercise in ‘covering your ass’. For example, you may make a statement here about what browsers you are going to support, or what CMS you are going to provide.

Arguably the strangest section in my fee proposals is the block called Non-requirements; why would you want to tell a client what you’re not going to do for them? It comes down to avoiding potentially costly confusion. You will find that most arguments in life arise as a result of ‘misalignment of expectations’ (e.g. “you said you were going to do this...” “you promised this...” “I never promised that!”, etc). This section is about nipping-things in the bud before they become problems. For instance; if you are creating an e-commerce site, you may want to say “the system will not support American Express credit card transactions.”

Now we come to the real meat of the proposal; the Project Components. If you’ve read my article on Project Schedules with Google Spreadsheets, you may be thinking that this section looks suspiciously similar to a project schedule, and you would be right. Once the contract is locked in, the project components segment serves as the basis for the project schedule. You have a task description and an hours estimate. The hour estimate is how you derive the cost of the project, and this is the point where some would disagree with my approach. I have had people say to me “you shouldn’t show a client tasks in such detail”, my answer is generally “why, they are paying for this project, shouldn’t I tell them exactly what they are getting for there money?” And yes, I have been questioned by clients on occasion about my hour estimates, but I have never failed to successfully defend my reasoning for an estimate.



There are a few other smaller sections I put into my proposals, but I will cover these quickly since they aren’t as important as the previous sections. I have a paragraph called Change of Requirements â€" the crux of this is to say “if it's not in the fee proposal, then it's not covered by the project cost”. I have an area called Third Party Costs where I say that hosting is a separate fee. Then I have the obligatory Terms section, which is very short â€" I just talk about payment terms and how the project will run. I have a paragraph titled Software Warranty where I say how long I will be fixing bugs for free (e.g. 6 months, 9 months, etc). Lastly, I have a Project Engagement section where the client signs to signify their acceptance of the project.

Note: this layout is what I use for my contracting work, but I have used aspects of it at some of the companies I’ve worked at.

Article reviewed by Nicolas Fontaine.

Wireframes and Mockups - Part II

Techniques for creating polished UI mockups.

Part 2 focuses on tools for producing polished UI mockups. Part 1 is more concerned with lo-fi approaches such as pen and paper-based techniques.

Over the past few years I have been exposed to a number of techniques for preparing mockups. Each approach has its strengths and weaknesses, but generally the best method to use depends on the project at hand. I don’t have a single preferred approach, but choosing the most appropriate style to use at the time can be a tricky undertaking.

HTML mockups â€" with the advent of such as like Microsoft FrontPage and its successor Web Expression, anyone can make cool looking mockups, to the point where it seemed as though all that was left to do was hand over the HTML to the programmers, and they would take care of the rest.



I’ve used FrontPage to make HTML mockups quite a bit in the past. Some analysts say its a very strong option for designs because it allows you to produce navigable HTML. From my experience, I don’t think its a good choice to use as a first draft system, it can be time consuming and lures you to distraction by unnecessary detail early on (i.e. making the design ‘look pretty’).

The biggest problem with HTML mockups is you have nowhere to put annotations (i.e. generally tech notes directed at programmers describing ‘under the hood’ functionality). As far as navigable mockups go, I’ve never found it to be a big issue with flat mockup structures. Generally people know where pages are going to go to, and in rare cases when a page is going to the wrong place, its nearly always a rudimentary task to direct it elsewhere.

There is one instance when a HTML mockup is appropriate straight away. This is when a complex new screen is being added to an already established interface. The reasons for this are beyond the scope of this article, but suffice it to say that experience has shown that its quicker then first creating a lo-fi version of the UI. One of the other great things about HTML mockups is that they’re easy to distribute to people.

Microsoft Visio â€" this is the tool I use at the moment for wireframes. It strikes a good balance between flexibility, professionalism, and speed. Visio is great for putting in tech notes without interfering with the wireframe itself, I generally put these in a sidebar to the right.



Visio interfaces come out looking nice and plain, which is what you want. It also has drop-in vector art for all the most common form controls you need (e.g. textboxes, radio buttons, etc).

I find that Visio is well suited for use with clients and their custom web applications. The only fault I can find with Visio is its hard to distribute files, few people have Visio installed on their computers (especially clients), but this is easy to get around, I just print wireframes to PDF.

Photoshop â€" mainly used by graphic designers to create compelling visual layouts. The beauty of Photoshop is realism. This can be quite exciting since it creates a real buzz on a project, as though things are starting to shift from concept to reality.

Photoshop is best used for creating a single highly polished UI screen. For example, just the home page of a business website, or just the landing page of a web-based application. I have seen graphic designers produce every expected screen of a business website in Photoshop, this is totally unnecessary. The client will get what their website is going to look like from just the home page (i.e. it establishes what the overall look and feel of the website will be).



The obvious short-coming of employing Photoshop is the skill required to use the program, it often takes years just to become proficient with the tool. Iterations can often be slower then other techniques, especially when a complex design with many layers is involved. On the plus side, distribution is a breeze since Photoshop can save image files which anyone can open (e.g. JPEG or PNG).

One of the perils of making wireframes which are seen by a client is the tendency to get distracted by cosmetic factors (e.g. client: “why is everything grey?”, “can we have that button in green?”, “that’s not our logo!”).

Generally what I do before designing anything is tell the client “I’m going to make some very rough mockups of how the screens will look. It wont be pretty, but at the moment we are trying to lock-down where buttons go, the general layout, etc”.

This is where methods like lo-fi prototyping or MS Excel can be helpful, because the screens can’t help but look hideous. The danger with mockups in HTML or Photoshop is that effort can be spent early on ‘making it pretty’. The problem with making things ‘look pretty’ at early stages is time gets wasted when iterative adjustments occur (which they will).

Iterations are the name of the game when designing a system, especially early on. If this is the case then you want to choose the approach which is going to allow you to churn out revisions at super-high speeds.

Outsourcing Coding vs Building an In-house Team

Perspectives on using outsourced programmers in a web development environment

A few years ago I was in Bali for a fitness bootcamp. Whilst watching TV late one night, I came across a documentary on the construction of an underground railway system in Amsterdam. I vividly recall one of the engineers being interviewed saying “it’s impossible, but we’re going to do it anyway”. When I think of some aspects of outsourcing, I remember this statement because there definitely are some tough challenges in getting outsourcing to work, but I believe it can be done.

I should begin by saying that by no means am I an authority on working with outsourced programmers, in fact, I’ve only done it for a few months total. My brief experience with outsourcing revealed both good and bad aspects of the approach, but more importantly, it opened my mind to the possibilities. I have noticed that some people seem to be against outsourcing for personal reasons, and that is surely their prerogative.

In some ways this article is a retort to a piece on outsourcing I recently read. The article in question is by Michael Bean and is titled The Pitfalls of Outsourcing Programmers. It is one of the selected works gathered together in the book The Best Software Writing I â€" Selected & Introduced by Joel Spolsky.



Am I attacking what the author had to say in the article? No way, it’s very well written and full of insightful information. Some knowledge of what the article is about is required in order to understand my perspective on the matter. I don’t want to re-write the article, so I will just cover the main points very quickly.

Michael Bean discusses the following ideas:

There has been a rush in recent years for US companies to send development tasks to India, China, and Eastern Europe.

Software development is design not manufacturing. Therefore, by virtue of its creative nature, it’s not something which should be sent off-shore.

People pay for ‘value added’ services or products. If all aspects of a company’s offering (from production to customer service) are outsourced, they cannot give customers what they truly desire.

Outsourcing customer service is equivalent to saying you aren’t interested in hearing what you’re clientele have to say.

The motivation behind setting up a massive IT work force overseas goes like this; “if Nike can do it with shoes, we can do it with code”.

The “but you are taking away jobs from Americans” argument is spurious at best, people in India or where-ever have just as much right to work as anyone else. We are living in a global economy after all.

When a business outsources innovation related task, they give away their competitive advantage. Over time, a company will lose their capacity to innovate.

Innovation suffers when people are spread across different countries since they can’t communicate effectively.

Outsourced programmers aren’t around for the long term. They tend to disappear after the project is over, taking with them any specialist knowledge they have acquired.

Completely outsourcing all of your development is a bad idea (i.e. both design and coding of the software).

The difference between United States and Indian time zones means there is no overlap between their working hours. This makes communication even more difficult.

Creating software is more about design then assembly. The ability to design is also considered an uncommon skill.

This is basically the crux of Michael Bean’s article. I’ve done my best to retain his core ideas, but obviously there is the risk of misinterpretation.



I have to agree that it is undesirable to outsource everything (i.e. both design and coding). In Michael Bean’s article, he doesn’t really go into what he means by design. To me, design means the functional specification (i.e. how the software will work from the user’s point of view).

Would I trust an outsourcer to write a functional specification? No. This is not meant as an attack on the skill of overseas programmers, it’s just unreasonable to think you could get a remotely accurate spec without meeting a client face-to-face. Would I trust outsourced programmers to create software based on one of my specs? Yes, definitely.

The other problematic aspect of Michael Bean’s article is that it doesn’t explicitly mention a division between shrink-wrapped software development and custom software projects. This is a major consideration. If you are trying to minimize production costs, then outsourced programmers are very well suited to custom development (and yes, maintenance is a big issue, but it’s a big issue with normal companies anyway). Reducing operational costs may be a very real concern if your business has investors or venture capital.

There are strategies for having outsourced programmers work on shrink-wrapped software, for instance; some Indian companies offer dedicated teams that only work on your software, they even come complete with their own dedicated project manager.

It’s true, you’re communication will take a hit, that is unavoidable. But you don’t get something for nothing. If you want to produce software for 50% of the normal cost, then be prepared to put up with some discomfort.

Luckily, in Australia we don’t suffer from the same time zone issues our American friends have to endure. In my experience with Indian programmers, I found they began to stir at about 12 noon, that’s just fine as far as I’m concerned.

Communication and project management tools are very important for successfully working with outsourced programmers. MSN or other instant messaging software is the key. I remember having three different IM softwares running on my computer at one point in order to keep in touch with everyone on my projects. A project management tool like Basecamp is also very helpful. A bug tracking system is another great idea, and an online schedule that can be viewed by everyone will make life a lot easier.

Perhaps this is a little simplistic, but it seems to boil down to this: outsourcing results in cheaper software development, but in-house teams produce better quality software.

Project Post-mortems

Running better projects by learning from the past.

The unfortunate reality with Project Post-mortems (also called Project Debriefing or Lessons Learnt) is that everyone thinks they are a great idea, but they rarely ever get done. I would say the main reason for this is because upper management generally doesn’t think its worth the commitment of resources. I have no sure-fire way for remedying this, but a good way of getting support from management is to stress that it wont take much time (e.g. 2 hours worth of debriefing meetings with technical staff, 2 hours to analyse the data, 2 hours to write the report).

What’s the point of a post-mortem you may ask? The obvious answer to this question is so you can learn from your mistakes (e.g. “I know for next time to start putting in the request for the SSL certificate much earlier”). But there are some subtler benefits to be had from creating this report. For one, it lets you analyse the effectiveness of your QA process (e.g. how many bugs in total were logged? how many bugs did you find vs. the client?, how many bugs seem to be the result of coders not following the spec?).

Probably the most important reason for undertaking a project post-mortem is the least obvious; its to engage technical staff, to ask them how they felt about the project. Far too often programmers feel they have been rail-roaded into doing things they didn’t want to do during a project, for example; cutting features, following technology choices made by management, having to work over-time because of poor time planning, etc. You must listen to people â€" that doesn’t necessarily mean you enact the ‘nerf guns for everyone’ policy your zaniest programmer requests, it just means sincerely listening to what they have to say.

If possible, I would suggest implementing at least one change based on your development teams’ feedback since this demonstrates you are actually listening. For example, if programmers are saying “we worked a lot of over-time to deliver this project, we should get time in lieu”, I wouldn’t propose getting them that time in lieu, I would instead suggest getting each programmer some kind of token gift to recognise their efforts (time in lieu isn’t the point, being appreciated is). Also, I’m against presenting gifts or bonuses to staff in meetings or in public settings. When management types do this, I think there is a certain aspect of ‘hey everyone, look what a good manager I am’ to it â€" instead, you do it in private, you just say “thanks Tony for the extra time you put into the project. I got you a Borders gift voucher for $30. I know its not much, but I just wanted to let you know we did spot the extra effort”.

The structure of the post-mortem report I use is very streamlined, being only two pages long. If your report comes out to be longer then that, consider stripping information until it gets down to two pages (remember, no one likes to read long documents). The process itself is broken up into three stages; debriefing the development team - where you ask programmers to give their thoughts on how the project went, data analysis - where you produce some simple statistics based on the bugs logged during the project, and lastly, writing the report itself â€" where you summarise both the feedback from programmers and make statements about the bug statistics. You may also want to include a conclusion at the end of the report where you ‘bring it all together’ and perhaps make some statements about what went well in the project and what could be improved.

When it comes to the debriefing session with the programmers, try find an independent party to run it. Their role is just to ask the questions you’ve prepared, note down the answers, and watch the time (two hours maximum, if it needs to go beyond that â€" bad luck). Having someone outside of the project asking the questions allows programmers to answer questions in an open manner; the project post-mortem isn’t a witch hunt. What sort of questions should you ask? Some examples would be; “are you proud of the work you did on the project â€" if yes; what in particular? If no; what went wrong?”, “what was the single most frustrating part of the project?”, “how would you do things differently next time?”, “what was the most satisfying part of the project?”, “which of our processes worked well?”, “which of our processes were hard to use?”, “if you could wave a magic want and change something about the project â€" what would it be?”, “did the customer participate effectively? If not, how could we improve this?”.

If you have been tracking bugs over the course of the project, you will be able to analyse these to produce some basic statistics. The sorts of stats I like to go for include; how many issues were logged during the project (and how many of these were bugs vs. feature requests), how many bugs were critical ‘show stoppers’ vs. low priority (like UI issues), how many of the bugs did you find compared to how many the client found (this is a good indicator of the effectiveness of your QA process).

Lets talk about the structure of the report itself. As is often my habit, I begin with a Document Purpose paragraph (e.g. “this document is a deconstruction of how the project went. The hope of this is to learn from our mistakes and identify successful processes which should be continued.”). You will most likely need to edit the answers given by the development team during their debriefing session; for instance, if one of the programmers has said “the client was a complete ass, he kept changing his mind every 10 minutes”, that’s probably not the best of things to be recorded in a document which upper management may see. This kind of statement would be converted to something like “members of the development team felt that the client was indecisive with regard to their requirements”.



For the Bug Analysis section, go for bullet point statements like “22.5% of all bugs logged were found by the client, the remaining 77.5% were found by us”.

Lastly, the conclusions paragraph is what its all about. Where you have a chance to make some grand statements which are backed by anecdotal statistics. You may want to say things like “the bug statistics indicate that as a team, we are not following specifications closely enough” or “based on feedback from the development team, there seems to be a consensus that a more detailed project schedule is needed”.

Will upper management really care about the project post-mortem report; probably not, at least not directly. But the post-mortem report is like a project schedule or spec, upper management generally wont be interested in the details, but they will appreciate that you have done it and it will be a reflection of your professionalism. Just be sure that it doesn’t become a mini-project in itself.

Hiring Programming Staff (Part 1)

Hiring great programmers for your development team (part 1)

Note: this article is split into two parts because of its length. The two segments are related, but each can be taken as a stand-alone article. Part 1 deals with phone interviews, part 2 focuses on written programmer tests.

The Phone Interview

Few would argue against the notion that the people on a project are the single biggest factor affecting its success. You could have an effective software development methodology in place, but inexperienced or unsuitable coders could destine a project to failure.

The task of finding a good programmer to join your team can be quite difficult and time consuming. I have to admit, I’ve done it the hard way in the past. A few years ago my boss and I spent an entire week trawling through résumés and interviewing people. We received around 240 applications and ended up interviewing 18 people. Needless to say, we got nothing done that week as far as our regular work went. This experience lead me to believe that there had to be a better way of finding top-notch programmers.

A starting point would be to post your job ad on a popular recruitment website (e.g. SEEK, or whichever online service has the biggest market share in your region). The structure and content of your job ad is ultimately up to you, but beginning with a short paragraph describing your company culture is a good idea. A common feature of job adverts for programmers is two separate bullet point lists; one for ‘must have skills’ and another for ‘highly regarded’ skills. You may also want to ask people to fill-out a skills matrix when they apply, this does two things: firstly, it weeds out ‘job spammers’ (i.e. people that just blindly apply to everything), and secondly, it provides a normalised method for comparing people instead of just relying on information which may or may not be contained in their resume.

After a few days, résumés should start arriving. Generally what I do is open up a résumé, press Ctrl-F and perform a keyword search for the most important requirement for the role. For example, if I wanted a .NET programmer, I would look for the keyword ‘.NET’ in a person’s résumé, if that particular word didn’t appear anywhere in the résumé, next (i.e. the candidate lacks the most basic of requirements).

There is an optional step you can do before contacting an applicant, and that is to ask them to complete an online test. In this situation, you would first review someone’s résumé to ensure they have the minimum skills for the position, then email them a URL to your online test. Based on the results of their test, you would decide whether its worth investing further time for a phone interview.



An online test does however require commitment of time to mark answers, but it will ensure that only the most technically competent people are progressing further. And yes, I am aware that a person can ‘cheat’ on online tests. For instance, they could have a friend sitting beside them helping them out, or they could be Googling the answers. But personally, that’s what I call ‘being resourceful’, besides, they will still have to survive a written test when they eventually come in for a face-to-face interview.

If you find a résumé that seems to be a match for the position you are trying to fill, then its time to consider a phone interview. This is where many people go wrong, they organise a face-to-face interview straight away. I believe this is totally unnecessary, you only need to meet perhaps 3-5 people from the total pool of applicants.

Now onto the phone interview. I work from a predefined script, a document about 2-3 pages long with questions relevant to the position. The first set of questions are what I call the ‘deal breaker questions’. If any of these fail, then you wrap up the interview and move on. The very first question always concerns communication. If you can’t understand what the person is saying over the phone, there’s really nothing you can do for them (you would terminate the interview).

The remaining questions would either relate specifically to the technology you are using within your organisation (e.g. “how would you rate your C# skills?”) or would be made up of very common interview type questions (e.g. “give an example of when you had to work under pressure”). To keep things simple, you generally rate a candidate’s answer as either ‘Bad’, ‘Fair’ or ‘Good’. As to how you asses an answer, that’s fairly subjective. However, each question can have a different weighting on its score. The reason for this is because a good answer to the question “what would you do if a project was running behind schedule?” is far more significant then a good answer to the question “why did you leave your last job?”. Conversely, if a candidate answered the question “how would you handle a difficult client?” in a negative manner, that may result in an actual deduction of points.



After concluding the phone interview, there is a Post Interview Analysis where you score the candidate on factors such as what their attitude and demeanour were like. These characteristics may be relevant if you are intending for the programmer to interact directly with clients. Finally, you tally the candidates score - the highest scoring people are the ones you want to interview face-to-face.

Where do recruitment or employment agencies fit into the picture? They are fine for the preliminary process (i.e. résumé review and talking to a candidate on the phone). They can be very effective in helping to short-list quality candidates. Do they need to be meeting and interviewing a candidate in person? I don’t believe so, it’s unnecessary and adds to the expense of the whole process.



A topic worth mentioning is the choice between hiring someone with a few years of industry experience vs. a recent uni graduate. There are pros and cons to both options, but it generally comes down to two things; personal taste, and how much money is available for the new staff member’s salary. Unfortunately, in-depth discussion of this topic is beyond the scope of this article, but I will say my own personal preference is to hire new graduates because they cost less and often have excellent production potential when given clear instructions.

Reviewed by Petras Surna