When explaining UML to novices, I find that the structure vs behaviour split is often the “Ah Ha” moment when things fall into place.  Without that, the names of the diagrams are just too much to digest in a single sitting.

 For those wanting more info, check out UML-Diagrams.org

I was clearing out some old things of mine and I came across not one but THREE steering-wheel locks. Around the time of my first car (late ’90s) the best way to prevent your car from being stolen was to have a steering wheel lock – a large clunky mechanism that you fastened each time you left your car. In later years, this mechanism was replaced with the gear-lock, a less-clunky and more effective security measure. And, this was finally replaced with immobilisers that were built into the car key and were seamlesss to the consumer.

While putting the steering-wheel locks in the trash I realised that technology, in the form of immobilisers and laser-cut chip-keys, was an example of where reliable & everyday technology took several years to come to the fore. Good-bye to the old, and Welcome to the new – technology, it’s nice of you to join us!

Half way through this review process, I was struck by the poor quality of the documents.  The requirements were generally vague and in several cases the bulk of a document comprised of large data definition (DD) tables that had been simply copied from another source.  I also became aware that the only hope for getting the correct solution developed by the software development house is if the developers themselves have an in depth knowledge of the environment and can fill in the blanks and improvise for the lack of content.

I had initially thought that the poor quality was limited to certain authors, or groups, but quickly saw that all documents shared this common thread.

It was soon apparent that teams that work closely with one another tend to have commonalities of how things are done and this was being carried through into the composition of documents, which were sorely lacking.

As an outsider to the enterprise, there was no way that I could use the documentation to get an understanding of what was built and the docs now only served to make the auditors happy by acting as a paper-trail, but having little substance beyond the introduction.

When faced with this problem of complacency, I find the following steps useful to self-moderate your own documents to ensure that they make the grade:

• Read the document as though you are an outsider.  Not everyone has an innate knowledge of the environment and these documents are used by the developers to build but also by internal staff as a reference point.
• Give reasons as to why things are done in a particular way.  We all know that office politics run rampant, but the reasoning and justification behind why something must be built a specific way is useful when you’re reviewing last years requirements or trying to analyse where a project went astray.  If you don’t know why things are done in a particular way, then ASK.
• If you’re documenting the rebuild of an existing process, don’t just state that it needs to work & function the same way – that’s a cop out!  Reference the original requirements, and if those don’t exist, then start documenting them – the requirements need to be laid out at some point, and now is as good time as any.
• Get some peer review going, especially for larger or more complex requirements.  The academic world relies heavily on peer review and for many good reasons.  Don’t be afraid to get critical feedback – it will improve the quality of your future work and also helps to share knowledge within the team.

But in the analysis field, the reuse of requirements is still very limited.  There are countless cases where the same functionality is re-specified and re-planned from scratch, and the end result in many cases is quite similar.  How many more times must I define and draw up requirements relating to security??!!  90% of it is the same each time.  Within the microcosm that I work, there is an element of reusing requirements and sharing between colleagues, but it typically doesn’t extend much further.

Yuri Cherna (USA) has recently published his results on this topic, and the findings are interesting.  It shows that 93% of respondents believe that requirements reuse is important but very few people are actively doing this.  The main drivers that respondents cite as to why reuse is important are … no surprise here … cost reduction, reduced life-cycle times and better quality.  But the biggest hurdle preventing greater reuse seems to be culture and the way we work.  Most teams are just not geared towards effective reuse – they don’t have the correct structures and processes in place, sharing between teams is often stifled due to office politics, and there’s typically no driving incentive to innovate or become more efficient.

With changing times, and tighter budgets, analysts need to come together (and management needs to come to the party as well) to create an ecosystem that favors reuse and rewards innovation – without these drivers we’ll simply not be able to keep up.

It shows some of the realities of what a building a startup really means – from huge sacrifices to conflict and stress-deluxe…

Check out the trailer below.

The book is written by Walter Isaacson, an accomplished author who has published books on Einstein, Benjamin Franklin and Kissinger – that’s some serious credentials!

The fascinating thing about Jobs is that he was an amazing visionary and master at creating highly sought-after products, to the point where he believed that he was almost God-like – an example of his delusions of grandeur being how he refused early cancer treatments and rather followed alternate therapies (which didnt work as well as he had hoped and turned to conventional medicine anyway).

It’s unlikely that I’ll stand in a queue to buy the book – I wont go to that extreme.  But I’ll certainly pick up a copy shortly after its available.

So, what is it that makes some projects run smoothly, while others become an utter nightmare? Well, it’s trust. And expectations.

The client needs to trust that the work being delivered is of top quality and most applicable for the given brief – there should be no second guessing. There’s a reason why you’ve hired a professional to do the job. If you want your friends’ daughter to whip up the job in her spare time, then feel free to question her abilities, but if you’re not the expert then don’t meddle in the space.

Managing expectations is the role of the supplier – the person doing the work. You need to be clear to the client as to what will be delivered and any caveats that they should be aware of. And if they trust that you are not blindsiding them, then you should all be on the same page.

Each party (client and supplier) has a role to play, but if you each play your part then things will run much better, everyone will be happy, and it will probably cost less as well!

• Full CMS
• Newsletter & email functionality
• Database driven, custom development

I found an interesting article outlining some examples of crowdsourcing before it become the latest fashion – interestingly, these date back several hundred years.  Does that still count?

But HTML5 might be the technology that puts a dent in that cash cow.  You see, with HTML5, we potentially have the ability to deploy applications straight from the web without the need for a ‘store’.  And, we can also develop a single version of an app, the HTML5 version, and dont have to create the Windows Mobile, Android, Symbian, versions.

In theory, this is a real game changer.  In practice, its going to take several years for this to really take off, and support on mobile devices for HTML5 needs to come quite a long way.  But once this is in place, it will be interesting to see how things shift.

Now, surely we’ll need an ‘App Store’ for HTML5 Apps – a sort of directory, and perhaps a vetting process … any takers?  Get in quick!