ColdFusion ranked in top four application servers by developers
by Neil Middleton 2:16 am Saturday, 21 March 2009.

Adobe announced today that ColdFusion has been announced one of the top four application servers available just behind Websphere, Geronimo and Windows Server. Those are some pretty well respected and prolific servers right there, so it’s good to see ColdFusion kicking with the big boys.

This report is the latest in a series of hints that ColdFusion is growing as a technology ever since version 8 came out in July 2007, after some ‘dark times’ recovering from the reputation left by it’s ancestor versions.

At Monochrome, we’re seeing more interest in ColdFusion too which is certainly proof in the pudding, so to speak. ColdFusion is definitely not as visible in Europe as it might be in the states, but it certainly looks like that is changing. Hopefully with the release of the next version of ColdFusion ‘Centaur‘ and the new ColdFusion IDE ‘Bolt‘ we’ll start to this continuing.

If you’re looking for a development tool that will let you create web applications, and back-ends for RIA’s, ColdFusion is definitely worth a look.


Comments (0)


Feature Upselling
by Neil Middleton 3:49 pm Wednesday, 18 March 2009.

Recently I found myself in the deep dark world of buying the various multi-colored accessories required to support a new born baby. Amongst the various things I needed to buy was a new baby monitor, as for some reason, our old one had decided to pack up completely in the four years it’s been sat in a sealed box (go figure).
So, anyway. Upon looking for said baby monitor I encountered the vast listings of products available on Amazon. All I wanted was a monitor that could let me listen to whatever was happening upstairs in little Max’s bedroom. Initially I was after something simple like this.

Features? Well, it let’s you listen to the baby, and also has a nightlight as a small added extra. Perfect for the requirements in hand - although the nightlight is an added bonus.
So, then I got looking for what else there might be, and from then on it gets a whole lot worse (unless you are especially paranoid). For instance, let’s take this one for example:

It can (deep breath) monitor humidity, monitor temperature, indicate connection drop out, indicate noise via a traffic light system, adjust the sensitivity, communicate over 330m (!) play lullabies, shine a night light, give an out of range warning, show when the battery is flat, vibrate and even tell you when it’s switched on.

Lovely.

However, think back to what your requirements are. You, as a parent, what to know if the child is crying. That’s really the only actually useful use for a monitor. Anything else is an up-sell to make the product more attractive to you, the buyer, and to make you part with that extra £60 you weren’t going to spend when you saw the first model.

So, how the hell does this relate to the web, and web applications? Well, think about your dream product, and then think about all of the wonderful things it could, all those snazzy little features that someone might find useful, things that would make it really cool.

Now picture Microsoft’s Word word processor - how many of the features in that application do you genuinely use day to day? I would guess you probably use the bolds and underlines etc, occasionally dipping into something more advanced like a table of contents. How often do you even look at any of the other stuff? How many of you can honestly say, for instance, that you’ve used the citations functionality, or the macros (and remember, word is one of the simpler parts of the office suite).

Now picture Word as the fully featured baby monitor, when all you really need is the simple one. You need a wordpad. After all, it does most of what you want, and you already have it.

So, Word is fine having all these features sat there waiting there in case you might want to use them right? Well yes, except you are paying for it. You are paying for all the features that you might want to use. You are paying for a whole load of things that you might need one day - if you’re lucky. It’s a common adage in the IT industry that only 20% of the features are used by 80% of the user-base.
So, why, as someone developing a web application would you want to pay for developing stuff that your users will only maybe use. Why would you not want to build fewer features, costing less money, less time, and ultimately making your application more stable.

Well, in part, marketing departments are to blame - they want to have one up on everyone else, they want their application to do one more thing than the competition, but remember - less software is easier to manage, less software means less maintenance, and less software means less bugs and less support needed therefore making happier users.

Build your product on one or two things it does exceptionally well, rather than the 90 things it does OK you’ll make your life a lot easier.


Comments (0)


Agile Requirements - How do you eat yours?
by Neil Middleton 3:09 pm Monday, 16 March 2009.

One of the things that I have been looking at a lot recently is the definition of what we, as a team, are building - a commonly missed task by many teams which can often lead to cowboy coding.

Now, there are many viewpoints on how this can be done, the age old preference being that of creating a 10,000 document that everyone must adhere to and be measured by. The trouble is, the document takes months to write, even longer to get approval on, and then an eon to code. By the end of this process, the document owner has retired, the development team have cycled their staff three times, and your dog has died. But, more importantly, because these days is moving so damn fast in business, your document is now worthless as half of the requirements are now invalid - either because the workflows in place have subtly changed or the market the product is aimed at has.

So, what do we do about this? Do we just ignore the requirement making it up as we go along, or do we do something a little more clever. Most people seem to leave it to making it up as you go along.

  1. Ask engineer how the damn thing works.
  2. Deafing silence.
  3. Crickets.
  4. Tumbleweed.
  5. Just start writing something. Anything.
  6. Give this something to the engineer.
  7. Watch engineer become quite upset at how badly you’ve missed the point of everything.
  8. As the engineer berates you, in between insults he will also throw off nuggets of technical information.
  9. Collect these nuggets, as they are the only reliable technical information you will receive.
  10. Try like hell to weave together this information into something enlightening and technically accurate.
  11. Go to step 6.

Well, at Monochrome, we’ve been doing Agile now for a fair while, and the key mantra there is

“Just barely good enough“

But what does this mean? Well, in essence, don’t bother doing anything until literally just before you need it, and even then, only do the absolute minimum to makes things work. If you do things to early, you’re opening up the risk of change, and if you do too much, you’re pretty much wasting your time (the minimum amount is just enough after all). This means no massive tombs of out of date guff, and also a lot less time spent writing.

For us, we find that documentation in the form of multiple screen wireframes that are annotated with functional detail tend to suffice, especially when accompanied by some background blurb to describe the things you can’t see. This is especially effective for two reasons - firstly it’s nice and visual, which means clients are more likely to read it, and it also gives you a nice document to directly compare your screens and functionality against - it’s almost testable.

Now, here’s a question back to you guys, all of which will be either reading, writing or somehow interacting with requirements on a daily basis - how do you eat yours? What do you find works, and what do you wish you could have?


Comments (1)