Gui Dazzles, Backend Frazzles

This is one of those truths that just hit me on the train this morning. You put a solution in front of a user, its the interface that gets them excited. All of the clever, performant and robust backend processing in the world won't impress them one bit. The backend is just 'stuff that can go wrong'.

For a case in point, Metastorm. I build applications for the financial services industry. A workflow solution has always been a good fit(document centric, process heavy etc...).

A few years ago, i was involved in a pilot of IBM's workflow solution. I was really impressed, it was well structured and the intrinsic use of MQ made orchestrating human and system processes seamless. The Pilot tanked.

Fast forward to last year, there was a crazy buzz in the business. Everyone was talking about Metastorm. What is it, its a workflow solution. I was confused, why the excitement now about a workflow/orcestration. I was lucky enough to work on our Metastorm implementation and now I understand where the excitement came from.

It's the GUI. The Metastorm workflow designer is fantastic easy to use and intuitive, the front end 'todo list' GUI is web based and similarly very nice.

I'm pragmatic about software. While I really like several aspects of the IBM solution but my customers are exited about Metastorm. Its already working for them and is capable enough to support all sorts of new solutions so I am working with it.

So just remember, if you want to build software that builds excitement, that can 'get in the door'. Get the GUI right.

Building Blocks

Building software is a bit like building a house with bricks (please, for a moment, forget my brilliant cake analogy described earlier in blogtime).

For a long time I have been using Visual Basic to build software. Building with VB is a bit like building with leggo bricks. The pieces are colorfull and easy to snap together. You can build almost anything but if you try to build anything too big, people will either say 'wow, i dont believe you managed to build a 2 story villa with lego!' or they will just snigger at you.

Building with Java is like building with house bricks. Nice and square. You have to use mortar but you can build big and small and you can put your house anywhere with pride. Building with C# is exactly like building with Java but the bricks have a little logo on them ;)

I dabbled with Ruby. Ruby bricks are pretty, they are translucent and have an odd otherworldly inner glow about them. To build with Ruby bricks, you dont need mortar and they dont snap together, you simply 'talk' them into place using a mystically mangled version of english.

'Ruby bricks, form of a payment....no...Payment class with ruby bricks create!....no...Please, sniff, just work...no...dang'.

Building with Ruby/Rails is like building a house...with a house. The only variable is how long it will take you to come up with the house. There is a demo on the internet that shows you how to do it in 10 minutes. It took me 2 hair pulling, eye scratching, forum crawling days to get close to the same result.

Most recently (about 2 months) I have been building with C/C++. I am finding this to be infinitely more fun than Ruby/Rails. So far I have managed to build, well, a brick.

keep you posted :)

You are living in a box

If you are like most people, you will be reading this humble blog post from within a browser application. If you are like most people, you are probably taking for granted many of the utilities and functions afforded to you by your browser, the toolbar with its convenient visually indicative images, the menu with its comprehensive and logically arranged functions.

You are also probably entirely comfortable with the way you are interacting with this blog post. You are reading it. Your browser is eminently capable of supporting this mode of interaction.. its a 'browser' after all, you can scroll through the post, change the font size, even print it.

This is all very comfortable and familiar but what if you wanted more. What if you thought this blog post was so fantastic that you wanted to capture it, ads and all. Say you wanted to add some notes to it, circle some of the more insightful passages, squiggle a mustache on the image of the author and then email it to your mates. Firefox cant do all that, neither can Internet explorer. These applications are not free form editors, they are merely browsers.

'But wait' you say, 'I can get this done!'. And you are correct, you can achieve this a number of ways. For example, you could print the post, edit the printout, scan or photograph the printout and create an image file. You could then open an email application, attach the image file and send it. Also, you could print-screen the image, Open a paint program, paste the image, edit the image, save as an image file, open an email application, attach the file and send it. You could also send an email to Microsoft or the Firefox community requesting free form editing, notation and highlighting and email integration features for their respective browsers, you could then wait a long time.

That these operations are doable is not at issue. All of the necessary tools to achieve this outcome, this deliverable, already exist on your computer. The point I want to make is how these tools are arranged. They are stuck inside applications, inside boxes. This blog post is the thing you are interested in right now (I assume this because you are still reading). If you want apply all of these wonderful tools to this artifact, you need to export, transform, import the artifact into each application in turn. This is horrible! You take this for granted, you cop this on the chin because, like most people, you have grown complacent and accepting about the limitations of software and the operating system.

Why cant we make software better. Why cant we make the artifact, the thing you are interested in right now, the most important thing? Why cant we free up these tools from their application boxes make the computing experience more intuitive?

Generic Solutions at your peril

After performance, the second best way to mess up your solution design is the decision to make something Generic. Get it right and you have built a future time saver, a well understood answer to future questions. Get it wrong and you can end up with a monster.

Before you build it Generic, ask these questions. If you answer 'No' to any of these, maybe you better design a tight, clean, focused - for purpose implementation.
- Is there already or do I absolutely know that the generic solution will be re-used and repurposed in the future?
- Do I have the time and resources to invest in building it generic now in the hope of a future payoff? Remember, you need to put your best resources on this, building generic is at least twice as difficult as building a good for-purpose solution.

If you have decided to build a generic solution, keep the following in mind
- Keep it simple. Please. If an implementation needs to be complicated, try to keep it in the implementation. Resist the urge to put everything in the generic solution.
- Try to use interfaces. These often give you the best pattern for re-useability.
- Maintain build time separation of different implementations, make sure you can discreetly recompile and re-deploy the different instances of your generic solution.
- Maintain Run Time separation of different implementations - Make sure that if one goes down (or takes too long) they all dont go down (or take too long). Note that this usually implies some sort of multi-threading in your implementation.

And Last of all, these are the signs that you are getting it wrong
- There is a large and complex web of static/configuration data for each instance. Most instances use only a portion of this static data and leave placeholders in the rest.
- New implementations are a headache for the original designer. They either mis-use the generic solution or the new implementors pester with endless questions.
- Consumers of the different implementations are involved in heavy hitting email wars with each other and are beginning to ask questions like 'Can I prioritise my jobs so they go first'.

Software is like cake

A completed software solution is like a cake, it has many layers. Rich spongey layers of relational schema and business logic and topped with oh so sweet GUI icing, yum :)

Unfortunately, because software is so much like cake, it is tempting to try and make it like a cake. First Ill design my schema, then Ill do all the business logic stuff then, last of all, Ill build the GUI. Although this approach seems logical, it has a fatal flaw....

Nobody will know what your cake tastes like until it's finished!

This is clearly hopeless, what if it tastes horrible? what if the business rules are wrong, what if the schema doesn't handle your projected volume? you have to mess around, trying to fix a completed cake or worse still throw the whole thing away and start again.

Make your cake a slice at a time

Take some subset of the features and build the schema, the business logic AND the GUI. Everybody can then get an idea of how the solution will work and if its wrong, you only have to fix that portion, not the whole solution.

Happy Baking :)

Who Signs off the Detail Design? - Having fun with the waterfall process

Being risk averse, un-agile and tragically unhip, my workplace labours under a 'Project Delivery Framework', essentially a formalised waterfall process attached to a clunky document workflow solution.

Recently, while reviewing a detail design document, an interesting point was raised :-

Who should sign off the Detail Design document?

The first and most obvious answer was the AD Manager. He has to sign off that the design is 'doable', robust, fits with and re-uses existing architecture.

The Information risk manager needs to ensure that the solution correctly handles things like passwords and encryption, he is also a no-brainer for signoff.

Beyond that it got a bit sticky. Should the BA sign it off?, the business SME? the project sponsor? What do these guys get out of such a document? The traditional response to this is as follows.. Somebody needs to ensure that the design and scope of the solution covers all elements of the detailed requirements. After all, what you want to avoid is the nightmare scenario where you deliver the product and then realise that it doesn't do something it should.

So I think, in the end, the non technical types do need to sign off this document but it should be very clear what that means. They are not signing off that the design is technically correct, they are not signing off that the solution is a credible answer to the delicate balance of performance, complexity and robustness. They are signing off that the proposed solution meets requirements. clearly also if you can structure the document so that it makes this relationship very clear (eg. 'Requirement X is covered by feature 1') then you are 90% out of trouble.
Of course, an agile process handles this whole conundrum a lot more elegantly and realistically but thats another story :)

Coming up for air

If you were wondering where where I was, I have been wrestling with a monster, a real nightmare. Too big to fit completely into 1 brain. Just the static data schema took 3 months to design. On top of that, 2 complicated GUI's (1 static data, 1 transactional), a core processing engine that takes instructions in one end and spits out files, reports and outputs to clients, internal users as well as 5 other systems with both a manual and an automated (Straight Through Processing) workflow in the middle.

Well enough moaning, its feature complete now (released to integration environment tonight, just bugfixing to go ) so I have a bit of headspace for blogging again, I might even have time to read a book :)

I found this article really interesting. Parakey sounds way cool cant wait to see it in action. I am a recent Firefox convert BTW, the Diggnation boys talked me into it.