Not Technical Really

RuleClarity Brochure site now up

2009-05-08T07:53:00.000-07:00

The software is still under development but the brochure site is up :)
You can check it out at http://www.RuleClarity.com

Tech Preview - Semantic Rules

2009-01-22T01:12:00.000-08:00

I'm very excited about this new video. It previews new technology that I have been working on. Feel free to comment good or bad. I apologise in advance for my abuse of clip art and slide transitions ;).

Gui Dazzles, Backend Frazzles

2008-07-07T16:48:00.000-07:00

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

2008-05-28T21:22:00.000-07:00

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

2007-11-15T05:03:00.000-08:00

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

2007-06-04T21:56:00.000-07:00

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

2007-03-02T05:24:00.000-08:00

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

2007-02-28T16:30:00.000-08:00

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

2006-11-03T05:49:00.000-08:00

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.

Naming States

2006-07-16T05:02:00.000-07:00

I want to talk about one of those 'bread and butter' topics that a developer or system designer will encounter frequently and perhaps will not think much about. Its states, or more precisely the naming of states.

If you have ever designed a table or a class to represent a transaction or any other 'non static' entity and plonked in a column named 'status' then you know what I am talking about.

Note for the Handyman Challenged: To paint a fence, you usually start by sanding it and then apply an undercoat.

The main problem I have with naming states is this.

Should the state name describe where the entity is in the process or what needs to happen next?

eg. After the fence is sanded, is the state of the fence sanded or ToBeUndercoated ?

Granted, sanded very succinctly decribes the current state of the fence, however, toBeUndercoated is much more informative. Consider a guy who does the undercoat painting. He can use the following (nice and simple) logical algorithm to find the next job to do.

Find the first fence where the Status = ToBeUndercoated

Allow me to contrast the above example with another. A line of Truck Cab & Chassis stands in the motor company holding lot. The fate or the Chassis (Winnebago, Mail Truck etc) wont be made untill an order comes in from a customer.

Does it make sense to describe the resting state of the Chassis as ToBeConvertedToAnRV? Clearly not, because we dont know yet what the chassis will be turned into. The most sensible name for the state of the chassis is FactoryComplete.

Its comes down to when you are able to make the decision about the next step in the process. If it is practicable to make the decision about the next processing step at the tail end of the last step, the 'WhattHappensNext' approach (ToBeUndercoated) is the most informative and sensible approach. If the decision about the next processing step is not or cannot be made untill the next step commences, then the 'current State' (Factory Complete) approach is the most sensible.

Software vs Religion

2006-06-28T05:03:00.000-07:00

Ok, inflammatory title for this post but I listened to a great Podcast talking about the science/religion debate and a couple of things really resonated with me.

Web2.0 and Memes

Firstly was the concept of Memes. Memes is ideas in analogy to genes where:-

memes have, as a fundamental property, evolution via natural selection

I Immediately thought Web2.0! I wont try to Define that but one of the things that sites like Digg.com and Blogger.com do is to catalyse the the evolution of memes, crank up the number of collisions between and tests of ideas. Its happening online right now on and software is making it happen!

Software as Meme

Then I thought, wouldn't it be cool if we could design elements of software that can self evolve be tested and 'compete' to fulfill a role within a process?

'We need software to be stable' you say. Thats fair enough but consider this. What if when you built and tested HelpyWidget1.0, everything was fine but now the processing volume has increased, the mid tier server is new, the Database software is new, the new Database forced us to upgrade the client drivers, none of the users ever use the feature xyz anymore but all of them call the software 'frank'. The environment your code lives in is changing, Code maintenance is boring and expensive. 'Bring on Evolving software!' I say.

As a side note, The Agile folks use 'refactoring' to adapt to changing environments and requirements and to constantly improve the quality. This is a sensible approach to the same problems...but evolving software is way cooler :)

Intelligent design Is not Necessarily good design

The program talked about the clash between Intelligent Design and Science/Evolutionary theory. The presenter made an assertion, 'if anybody has seen the design of the human prostate, they wouldn't believe in intelligent design'. Then I thought, I see crappy design in software every day. Developers are intelligent, building software fits with intelligent design. The assertion that a designed system is a perfect system is only correct if you assume the designer is perfect. The simple fact is that for most humans, bad design, bad software is easier than good design, good software.

Auto Update Equals Auto Exasperation

2006-06-24T16:50:00.000-07:00

So Papa calls last night and has a full 30 Minute spew about his new, ADSL connected computer. After sorting through the confusion, I discover the evil culprit....Auto Update.

Case 1) 'Whats Java and why do I care?'
So the Java Runtime environment was installed by default on Papa's new pc. Fair enough, you need it to do lots of cool stuff on the internet. The problem started when the JRE decided to check the internet for an update and ask Papa if he wanted to upgrade. Now Papa has decided (sensibly) to say 'no' to everything he doesn't understand (most things) but he still found the whole thing confusing (was it a virus?, was it adware? does he need it?).

Case 2) 'Whats Adobe reader?'
Basically same scenario, Adobe auto updater this time but it was also tangled up with hotmail...Mrs Papa saves a pdf file local and then wants to forward the mail on with the document, double clicks the file, adobe reader checks for update, asks the question....Total confusion.

I am a power user, and am in front of a PC a lot. I think auto-update is cool because I like things to take care of themselves. but Papa (and a lot of people) just want their computer to be quiet and only do things when they ask it to do something. There is enough crap to worry about with Adware popups and scam emails, why should legitimate software add to this burden with auto-update confusion.

Workflow Doesn't work

2006-06-24T06:22:00.000-07:00

According to a very learned and wise colleague of mine, while developers will always say that they are pro workflow, none of them really believe
that it works. Personally, since being involved in a workflow project, I have always liked the idea. Its so neat and tidy, the yucky business rules that no developer really truly understands are zip-locked away in some XML document or modeling tool and we can just code neat little boxes that respond to requests from the workflow system. If the flippy types in the business change their mind about a process, you can just fiddle with the model. The code can stand stoicly firm, clean, pure and sexy in the twirly maelstrom of the business process.

I have to admit though, I have never seen workflow actually work. The workflow project I was on never got to technical implementation because they made a headcount save by rearranging the business units more efficiently after reviewing the business processes (the solution didn't involve a .sln). Another colleague of mine says that 'every insurance business in London runs on a workflow platform' so I suppose the statement/heading at the top of this page is debatable.

I decided though to ask the question,

if workflow doesn't work, what does?

This is very difficult, so I gave up on that question and decided to write down a few things about people and systems and work that I was pretty sure were true..Well it started off that way and went a bit pear shaped towards the end...Anyway, this is what I came up with.

Warning, Stream of consciousness follows

People at work have things to do

Systems at work have things to do

Things to do have only a few important attributes. What exactly to do, which people or systems can do them and when they need to be done by.

Sometimes people do the things to do, sometimes systems do them, it doesn't really matter which. People are generally good
at some things and systems are ,generally, good at other things. Some things to do can be done by either people or systems, the only difficulty
with this is, often system friendly instructions and people friendly instructions look a bit different.

An object, for example, a data row or document is fixed in space, it doesn't move (conceptually any way),
it doesn't flow, it is not in a pipeline, it is not transported, it is not itself a thing to do. A thing to do may contain references to objects. The format of these references is not really important, so long as a person or system can find the object or objects it needs to do the thing to do.

A lot of things to do are very similar each time we do them. It seems reasonable that things to do
should be able to be copied from older things to do. Other things to do are completely new and novel, that's ok to, as long as somebody or some
system can do them.

Sometimes after doing a thing to do, it is appropriate to create another thing or things to do. For certain types of
things to do, we may really know for sure what that next thing to do is eg. after receiving a fax instruction to move some cash into an account, the next thing to do should always be to call back the owner of the cash and verify the details...Often when this happens, some or all of the references to objects are passed along to the next thing. Sometimes there may be nothing to do next, sometimes you may not know what the next thing is until you have finished the first thing.

A thing to do is never done until you have created the next thing or things to do, or decided that there is nothing to do next.

People and systems need to know what things to do, they can do.

Systems like to have their things to do in a queue. Systems are good at processing queues.

People find queues depressing. When people look at the things to do that they can do, they
may like to see these things floating, like little blobs of wax in a colorful lava lamp. When things to do are not very urgent, they might float low
in the lamp where the colour is shady and blue. Inevitably, things to do become more urgent and may be seen to float upwards where the colour is brighter and more orangey. Things to do should never appear to flash, become underlined or jerk about wildly. A bit of bobbing on the surface may be ok though ;)

Hey what's with the Funny Name

2006-06-09T05:56:00.000-07:00

When I was in high school, I was handed one of those 'What career is good for you' kits by the school careers councilor. So I ticked all the boxes and added up all the scores and discovered that with my mix of empathy and analytical skills, I was perfectly suited to being a psychologist! With typical aplomb and common sense, I proceeded to do a degree in Materials Science and now work as a software developer/architect.

So despite my career, if you ever come round for a BBQ, please dont ask me..'should I buy this PC' or 'I am getting this funny error from Firefox'. I'm not technical really but I do know a but about software development and am learning about user focused design. I hope that my odd ventings and rantings may be usefull to some other unfortunates in the software game.