Programmers like to program - it’s what we do. Just like doctors like to doctor, preachers like to preach, and waiters like to wait. We like it so much, we don’t want to do anything else. We don’t want to worry about all that pesky advertising; we don’t want to spend hours or days choosing just the right words for our web-site; we don’t want to bother with all that marketing stuff - after all, the product is good enough to sell itself. Right?

Wrong.

This is the fatal flaw that destroys many small software companies. Starting out, our knowledge base is limited. We know how to write code and design software, so this is what we do. We release a version 1 of our first product, listen to feedback, and follow it up with a version 2 a couple of months later. It’s good enough to sell, but we don’t know how to sell. It has the potential to sell well if we could just get our message across, but we don’t know how to market.

The next version of PageFour is on the drawing board. After taking feedback from existing users - and scratching my head over a bottle of Merlot - a list of changes and enhancements has been carefully put together. It’s a strong list, and the product will be stronger as a result. The temptation to take this list and start writing code has been overwhelming. Six hard weeks of work, followed by a testing run, and version 3 would have been ready by the end of March.

The road to failure is filled with writing code.

For a small software company to succeed, the two parts of the business must be given equal weighting. Yes, design a great product, and keep making it greater. But we need to work just as long and hard at marketing the product, at getting our message out there.

For most of our careers, we looked down on the guys in marketing and sales, as if their jobs were somehow beneath us. Now, our success depends on learning their skills.

My development plan for PageFour has shifted somewhat. The list remains, but the time frame has changed. Instead of working for two solid months, testing heavily and releasing, I plan to release after each feature is implemented. This means four releases over the next four months - a steady development of the product, progressing side by side with the marketing.

No more mad rush to write code.

My TV remote has twenty nine buttons I’ve never used; the VCR has thirty; the DVD player twenty six. And before you ask - yes I really did count them all.

There’s a name for this kind of excess: it’s called featuritis, and it pops up in all sorts of design failures. I stumbled across an interesting article on The Featuritis Curve the other day that goes a long way to explaining why we have to endure this.

Good designs are obvious. When aesthetic and functional beauty combine, the result is not just pleasing to the eye, but a pleasure to use. This is why the iPod is so popular. Chances are it’s not the best value for money - there are probably other music players that produce a better sound, have a longer battery life, or have a whole raft of additional features - but the iPod looks like a work of art and is simple and straight forward to use

When have you ever heard someone boast that they couldn’t program their iPod?

So who should we be designing for anyway? The 98% who use a small number of features all the time, or the 2% who use advanced features once a week? Wouldn’t it be a whole lot simpler if my TV remote had a single advanced button that opened a menu for all those quirky, unused features?

Make no mistake here - you’ve never used those mysterious buttons either, and you probably don’t know anyone who has.

Software is often designed in the same way, for the same 2% of users. Feature after feature is added, each just as prominent as the one before, with little thought given to the complexity this adds to the product as a whole.

At the nine to five over the past few weeks, we’ve been putting the finishing touches to a new product aimed at the business market. It’s the sum of eighteen months work for four programmers - plenty of time and resources to produce a first class piece of work. But it’s not first class. Dialog after dialog contains features, options, and checkboxes that no one really understands. The poor unfortunate writing the help file has to suffer every time he asks for an explanation of feature X. In some cases, even the person who designed the feature can’t explain it without re-reading his own code, and even then the explanation can be patchy.

This isn’t funny, it’s critical. Complexity like this is nothing to be proud of. But why does it happen?

You can chant ‘keep it simple‘ until you’re blue in the face, and everyone around you will nod their head in agreement. The problem is, we all have a different perception of what simple means. Programmers are geeks; they belong to the 2% who use all those weird buttons on the TV remote, and for many of them these features are absolutely essential. The sales and marketing types want to be able to say that their product is better than the competition because it can also be used to fry an egg, or do your kid’s homework. But that does not make it better.

Features are not important, it’s the product as a whole that matters. Does it do what it was designed to do, and does it do it fantastically well? Does it look good, run smoothly, and behave intuitively? If it doesn’t, then all the features in the world will not save you.

More features does not equal more sales. More features does not make for happier customers. More features will not make your product better than the competition.

PageFour has reached the stage where featuritis first raises its head. Over the past couple of weeks I’ve been putting together a future development plan, and my focus throughout has been on identifying those mysterious buttons that so few of us ever use. Only time will tell if I’ve succeeded.

When I first created the web-site for PageFour, I’d vaguely heard of the term Search Engine Optimization. It was one of those things I assumed I’d get around to eventually, but it would just have to wait until the more important stuff like rolling out the first, and then the second release of PageFour had been dealt with.

I was wrong.

Had I read those few chapters months ago, I would have realised the importance of the URL, and chosen a domain name with more relevance to the product. www.imbt.co.uk has no meaning to anyone but me. I know it’s short for It must be Tuesday; I know IMBT Software is the company name; but does anyone else? And would it make a difference if they did? It’s the product that matters, not the company.

PageFour is software for writers, and the new URL is www.softwareforwriting.com.

It’s been live now for about a week and has already been picked up by MSN’s very industrious robots. The Google team however, seem to be sleeping on the job, and let’s not even talk about Yahoo. Still, it was something that needed to be done, and it really couldn’t have been put off any longer. All the links that I control on other websites have been changed, and the new download sites PageFour has been submitted to each carry the new URL.

Things are finally moving in the right direction.

With the release of version 1.29 of PageFour, complete with one change to a single line of code, the crackers have returned.

My personal opinion of the people downloading my software from these illegal sites is that they’re one candle shy of a decent birthday cake. If I were giving the product away for free, they probably wouldn’t touch it. After all, freeware is just so common! As soon as they realise they can steal something other people pay for, and do so from a shady web-site with Mandarin text, PageFour suddenly becomes hot property.

I can just picture the emails flying to one dank bedroom after another. “Check this out. You can use it for that novel you always wanted to write about life in a twelfth century Cistercian monastery!”

Get a life guys!

Still, some of these sites have a halfway decent pagerank, so the links do perform one useful service.

PageFour has been cracked.

For those of you too honest to know what cracking is, let me enlighten you. It’s when some shady hacker type character working out of a dingy bedroom in Bucharest downloads your software, hacks it in such a way that any license restrictions are overridden, and releases the ‘crack’ to the entire world.

Version 1.28 went live last Saturday evening, and by Wednesday the deed was done - downloads went through the roof; referrals from very shady sites in Hong Kong and Russia were way up; and I came within a hairs breadth of a coronary.

Team AGGRESSiON were the party responsible. Note the small ‘i’ in AGGRESSiON - I’m sure it has great meaning amongst the hacking and cracking fraternity.

I’ll be honest, I had a bit of an emotional reaction when I found out. The cursing and swearing was heard from Hampton Court Palace all the way to Putney Bridge. I spent a frantic hour adding URLs to my htaccess file and worrying over the bandwidth being consumed before retiring to a very unpeaceful rest.

But the dawn of a new day brought a whole new perspective.

Does it do me any harm?

Not that I can see. So there are hundreds of new PageFour users in China and the developing world - all churning out novels at a ferocious rate thanks to my innovative designs. Who knows, I may be single handedly responsible for a literary renaissance in the far east.

Would any of these people who downloaded the cracked software have actually bought the product? A simple no.

Will it increase the visibility of the product? Well, it won’t do it any harm.

So where’s the downside?

Honestly, these isn’t one that I can see. Downloads have continued over the past few days, though not at quite the furious rate of days 1 and 2, and my bandwidth is pretty high, so no problem there.

I choose to take it as a complement. After all, they only crack the good stuff, right?

It’s been four days since the launch of PageFour v 1.2, and things are looking promising. Downloads are modestly up, but more importantly, feedback has been excellent - I know I’m on the right track.

Over the past six years I’ve worked for two small software companies in the South East of England. Both companies designed and sold their own products; both companies considered themselves leaders in their field. In all those years I never received any indication from clients that the products were anything more than adequate to the job at hand.

Now, this is hardly surprising. If you buy a product and it does what you bought it for, most of us would be content to let it end there. We may tell our friends about it, we will almost certainly carry on using it, but why bother contacting the company?

In the past month I’ve received a handful of emails from users of PageFour telling me how happy they are with it; how it meets their needs and fits their writing requirements so well.

It’s very uplifting to receive emails of this variety, but I think the real message here is not that my product is so good, but that the alternatives out there are so weak.

All the big word processors are designed for business users - not surprising, as this is where the money lives. Much of the writer specific software I’ve looked at is far too rigid and compartmentalized to fit the real needs of more than a handful of users.

PageFour was designed to be flexible. The central element in the design was that the writer decides at all times how to structure and approach their work. It is this flexibility, more than anything else, that people seem to like.

It’s make or break time for PageFour. Version 1.2 went live at half past midnight.

One of the prevailing opinions in software development circles is to release early and release often. By doing this, you develop your product in line with your customers. Features being added to the next release should always be features existing users have asked for, or potential users have queried before deciding not to buy.

Releasing against a six monthly or even worse, a yearly development plan is catastrophic. The software market, and the IT industry in general changes too fast for such long term plans. And one year is a very, very, long time.

Small software companies have one huge advantage over the giants, and that is their ability to do things quickly. For Microsoft to release a new version of MS Word is probably a two year undertaking - for a company of one or two programmers, two or three months is not unrealistic.

I’ve been following this maxim with PageFour since day one. Version 1 was released on October 8th this year. The world did not shake, but the feedback and suggestions were inspiring. Two months later and I’m feeling very confident about the new release.

The only question now is: will the world shake? And if not, can I make it shake?

The beta version of PageFour 1.2 was released yesterday evening to little fanfare. There were no fireworks at Hampton Court Palace, no champagne in ridiculously tall glasses, but there was plenty of satisfaction. I just love releasing things on time.

Unlike the previous beta run, this testing phase is by invitation only. One of the lessons I learned a couple of months ago, was that for every ten people happy to download your beta software, only one will take the time to look at it in detail and offer serious advice or criticism. The strongest and most productive feedback I received on version 1.1 came from only four people.

I’m going to own up now and say that there is one bug in this beta version. The bug is insignificant and has no effect on any work being done. It is purely cosmetic, and I hope no one finds it. I hope no one finds it because it’s going to be a bugger to fix. I’m determined to fix it, even though the writers of the third party component responsible are swearing blind it’s a Windows bug.

I don’t believe them, which means next week is going to be fun.

When it’s a folder.

The first release of PageFour suffered a minor identity crisis. It was trying too hard to fit into its target market. The product was aimed from the start at the writing community, and all its features were written with that community in mind. In line with this, the terminology adopted by the user interface followed a ‘novel’ theme, with chapters and pages predominant.

The problem with this was that the chapter and page format just did not fit. From the start, it all felt slightly off, but it wasn’t until some of the early PageFour users became vocal in their confusion that I really sat down and thought about it.

When you start writing onto a blank page, over time that page becomes a chapter. You may have old and new versions of this chapter, as well as notes and character summaries, but the final chapter will be written on one page in PageFour. The pages within chapters format was just plain wrong.

The upcoming release of version 1.2 has allowed me to address this confusion by removing any reference to chapters in the user interface.

From day one, the most important element to the PageFour design was that it imposed no restrictions on the way a writer worked. I wanted to avoid what I saw as the major pitfalls of other writing software: the rigid compartmentalising of the writing process - character summaries here, plot outlines there, linked in just such a way, each chapter in a certain place, etc.

PageFour was to be wide open; capable of being adapted by any writer to the way they chose to write. Put your plot outline wherever you wish; build your character summaries in any way you choose; manage your chapters in your own unique way: as different pages and versions within one folder, as a simple main page with notes alongside - whatever works for you.

The revised naming conventions, coupled with the new Multiple Notebook feature make all this possible. Version 1.2 of PageFour consists of any number of Notebooks defined by the user. These Notebooks contain folders, again defined by the user, and each folder contains pages.

It really is that simple. A folder can contain a chapter; it can contain a series of character sketches; it can contain an entire novel. It can contain whatever you want it to contain.

The simplest solutions really are the best.

When I rolled out the first beta version of PageFour over two months ago, I was convinced that the only changes I would need to make before releasing the full product would be a few minor bug fixes. I could not have been more wrong.

Like so many software designers before me, I made the fatal mistake of assuming I knew what was best. I assumed that because I had decided particular features were important, my potential market would feel the same; that because I felt something was acceptable in its current form, everyone else would agree; that because I worked in a certain way, so too would the thousands of writers out there who I was writing PageFour for.

In retrospect, I can see how my first beta release was more about testing the idea behind the product, than testing the product itself.

I’ll be honest - it threw me just a little at first. But I took it on the chin, went back to the drawing board, and made many of the major structural changes that were suggested. The end result was a first release that was far superior to the version I had planned.

An idea in isolation is just an idea - it needs refining before it can become anything substantial. Developing an idea into a product for use by other people cannot succeed without the input and knowledge of those people.

Version 1.2 of PageFour is due for release in four weeks. It contains many of the suggested enhancements from the previous beta run not yet incorporated; enhancements that mark a significant improvement in the product.

The beta version of 1.2 will be released next weekend. This time around, I can’t wait for the feedback.