Archgrove - Implicit Definition

Six down, three exams to go. I’ll be all finished by Friday, and can return to the clinical embrace of development. A homecoming to look forward to!

Well, when I signed up to be a mature student, I knew it would be a lifestyle change. However, I didn’t entirely count on the workload level. Nine exams over the next 2 weeks, and though it’s a nice change for there to actually be a “right” answer, it’s a little wearing.

Posting may be slow until then.

Now we have a more detailed specification of the problem, it’s time to start thinking about how we’re going to solve it. A problem is only really solved if the customer thinks that it is – a solution that is perfectly valid to you might be totally unintelligible to them.

In the past, I had a tendency to solve the problem from my perspective. To take an example, when developing a web CMS, who wouldn’t view a website hierarchy as a list of “entities”, with “container entities” and “file entities”! Files and folders are so archaic, right? These new metadata tagged virtual representations are much easier to work with!

Well, to me, yes. But to the person who just wants to make their website attractive to Mom and Pop purchasers, no. They deal in a totally different set of concepts, and as they’re the users we must take both our technological expertise, and marry it with their end user expertise. In other words, write software they can use, and get the most out of (rather than spend their whole life in just 10% of your work because the other 90% is too confusing).

Step 2 : Think about it not just as a programmer, but as a user

This is probably why the current “free software” is fantastic for those of us in the hacker fraternity. We have the same mindset as the people that wrote it, and will clearly see that a “shortcut” is actually a symbolic link added by the file system, and not a pretty icon with an arrow on it. But 99% of end users don’t care – they just want to have Word run whether they click on the “desktop” Word, the “Start Menu” Word, or even a Word document.

As we’re going to design both an end user application and a programming, we get to see two user types in this project, hence satisfying both our geek side and our pragmatic side. This is a trick I’ve come to use on boring projects. If the software you’re writing is the most tedious piece of work you’ve ever seen, view it as a challenge in programming terms. Yet another online form processor? No! A chance to construct an elegant method of validating form input!

Of course, this can lead you down the route of ego massaging. A beautiful technical design, but either no solution or a solution that took 10 times as long as just writing the damn thing. I’ll discuss this next time, when we look at the specifics of the API design.

As mentioned earlier, the end goal is a Spell checking application that I can leave running in the background, and call into life at a keystroke for quickly checking and correcting a word. All well and good, so let’s fire up Visual Studio and get to it!

Oh, wait. This idea was meant to create me a new development style that fixed problems I had with my old style. I guess I’d better stop and think about it first.

The first thing I notice is the project, whilst simple on the surface, is not very well defined. I’m spell checking something, but I’m not sure what.

Step 1 : Actual programming is a step in solving another problem, not the problem unto itself

Whilst I (and other people) program just for fun, 99.9% of the time, we’re solving a problem. So, let’s go back to the “client”, and work out what we’re actually doing.

It turns out that I want to spell check individual English words, checking them both for typographical errors and for spelling errors caused by not knowing how to spell it other than by phonetically guessing. I want this both in a small tray application for windows, that I can use for a “click, type and correct” problem, but I also want a reusable API I can embed into my other programs. Hey, I’m a geek! Because I’m also an awkward, typical client, I won’t know if it’s what I want until I see it and ask for something entirely different.

So, let’s get our customer requirements down in a list.

I want.

• A spell checking API
• That works for English words (But maybe other languages later)
• Corrects typographical errors
• Corrects phonetic spellings to real spellings
• Is reusable in many different application types

I also want.

• A spell checking application
• That sits in my Windows system tray
• Pops up when I click on it/press a hotkey
• Lets me type in a word
• Quickly tells me it’s correct, or provides the correct spelling for me

Right, now we’ve got a real customer specification, something I was previously quite bad at acquiring. Of course, in the real world, I won’t be the customer, but it’s the best I can do for now.

With math and real life keeping me busy over the last 6 months, I’ve not had as much time as I wanted to work on one of my major passions - software development. I decided to change this over the last month, using spare minutes here and there to create and refine a new development style that I hoped would allow me to create polished work of higher quality with greater speed. Pretty much what every programmer wants, and what every programmer has his or her own opinions about.

Being a natural sceptic, my buzzword subscription policy is “Just don’t”. AJAX? A cleaning product. TDD? You mean you never tested things before? Agile development? No, I just write software in a chair, not hanging from monkey bars.

OK, that’s a bit harsh (and not entirely how I feel) but as an industry, we’re currently suffering from hype overload with regard to development methodologies. The “coming of age” of powerful IDEs, (more) modern language design and the Internet has created opportunities for each methodology camp to shout their ideas from the rooftops, with news starved IT journalists echoing it back. There is some good buried in the acronyms, and my idea is to dig a bit, and pan the gold from the mud. I’ll do this during the creation of a “soup to nuts” project that will scratch an itch I have.

Being a big IRC user/notepad user as well as a terrible speller, I’ve often found a need to quickly validate a word I’ve typed. Not wanting to load Open office/word every time, I decided one day to write a small spellchecker that I could leave running in the background, and call into life as a keystroke. This being a simple, tightly defined project, it seemed ideal to use it as my test candidate when developing my shiny new authoring style.

So, to war! As I write this, most of the work is done, so in the next few posts, I’ll detail what I did, how I did it, and how well it’s worked for me. At the end, I should find myself with a usable product that I can keep on my CV as well as post for the community to use. Let’s see how it goes…