Everything looks like Bootstrap

Ever since I started using Bootstrap I can't help but notice that 3 of 4 technology websites I go to seem to be using it. Time to just incorporate it into HTML5?

Kids these days..

I recently started doing some development again on the side, and I can't tell you what a difference there is from the last time I coded. I'm using Ruby on Rails and developing is just a dream. Things like Bootstrap and JQuery make developing a functional and good-looking apps so easy.

Compared to the bad-old days of dodginess in the mid-90s it's so much easier. It's so much better than the early web MVC frameworks where I had to copy and paste the same 300 lines of java and XML code for every model; and let's not even mention the early days of Perl and PHP.

Nothing useful here, just wanted to share.

BABOK Requirement Types in Haiku

Business has a need
Stake holders require outcome
Function shows the way

(This may be one of the geekiest things I have ever done.)

Classic Software Engineering Essay

While I was doing some research for a requirements health check offering for work I came across this classic article that I remembered from an old battered copy of mythical man month called “No Silver Bullet”.


What it drove home to me was how little has changed in the 20 or so years since it was published. Good requirements are still central to the value IT delivers and we (as a society) still suck at them.

It’s an old article (1987) but still as valid as the day it was written. I especially love the way you can see the ideas that will come to be known as agile and cloud in it.

Article Text:http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html

Lecture Notes on Article:http://www.cs.colorado.edu/~kena/classes/5828/s09/lectures/02-nosilverbullet.pdf

It's amazing how little the fundamental problems of building solutions have changed despite all the technical hype. Especially this quote “I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.”

Requirements are probably the hardest part of the solution development process, and the part that adds the most value. If technical design, project, and implementation are all fantastically then the result is that the solution is on budget and on time. But if the requirements and solution design are fantastic then it makes a real impact on people’s day to day lives, how well they do their job, and the effectiveness of their enterprise as a whole.

If you have an opportunity I recommend reading the article on the way home not in the office on your screen. It’s way too dense for that.

P.S. Some of the article is a touch dated. Time-Sharing is no longer a big change for example, and OO is not an innovation anymore; however Ada remains sadly under-used. Other bits are very prescient, such as a move towards iterative change driven development (e.g. agile), buy-vs-build, and even a touch of cloud.

Service/Security Levels

Here's an idea - next time you need to classify a service, product, or outcome based on quality - use a method that matches the service. Don't fall back on the old Gold/Silver/Bronze. Instead use a classification that gets across the trade-offs that are always implicit in classification.

For example when I'm doing security classification I like to use Titanium, Steel, Glass. This gets across that working with titanium is quite difficult, steel is easier, but if I want the service to be open and easily visible glass is a better choice.

It also gets away from the idea that more expensive is better.

GRACEful RAPID Decision Making

I love RACI matrices as a tool, but it always bothered me that governance wasn't covered and that the I for "Inform" was a little weak. Below are two alternatives, once if which I made up without meaning to, the other (far better one) focused on how to make operational decisions and changes.

I wanted to cover "Governance", and change Inform" to "Engage" which has the added bonus of being a meaningful word

• Govern: Oversight and stage-gate owner. May override decisions or act as impasse breaker.
• Responsible: Actually performs the activity and recommends preferred option.
• Accountable: Will be held responsible for the activity being performed, decision making authority
• Consulted: Opinions consulted in early decision stages, and kept aware of any outcomes
• Engaged: Made aware of decisions, issues and outcomes throughout project

Bain and Co also have a great model called RAPID that's better suited to operational decisons that setting up project governance:

• Recommend
  
  • Making a proposal on a key decision, gathering input, and providing data and analysis to make a sensible choice in a timely fashion
  • Consulting with input providers-hearing and incorporating their views, and winning their buy-in
• Agree
  
  • Negotiating a modified proposal with the recommender if they have concerns about the original proposal
  • Escalating unresolved issues to the decider if the "A" and "R" can't resolve differences
  • If necessary, exercising veto power over the recommendation

• Perform
  
  • Executing a decision once it's made
  • Seeing that the decision is implemented promptly and effectively
• Input
  
  • Providing relevant facts to the recommender that shed light on the proposal'sfeasibility and practical implications
• Decide
  
  • Serving as the single point of accountability
  • Bringing the decision to closure by resolving any impasse in the decision-making process
  • Committing the organization to implementing the decision

http://www.bain.com/publications/articles/who-has-d-how-clear-decision-roles-enhance-organizational-performance.aspx 

Easy to Use vs Hard to Misuse

It’s an awful thing to admit, but I think old mainframe green-screen applications are easier to use than slick web applications; where modern web apps have the advantage is that they are hard-to-misuse. “Easy to Use” is very different to “Hard to misuse”. They are two very different things with very different implications for system strategy, enterprise arch, and business requirements.

 

• Easy to Use: As a regular user or seasoned operator I want to be able to do things effortlessly with a minimum of interruption so that my workflow, thinking, or customer service is not interrupted.

• Hard to Mis-Use: As casual user or end customer I want it to be obvious to me how to accomplish normal tasks so that I can complete teh activity with a minimum of frustration and get on with my day.

 

I’d illustrate with calculators. I know I over-use the calculator similes; but I’m a geek and if you’re reading this chances are you are to.

 

Of my four favourite calculators in my house, I consider them all “easy to use” – but in really different ways:

 

• My HP12C financial calculator is simple for complicated calculations (Thanks to RPN) or financial calculation (Thanks to dedicated functions; but my wife can’t even use it to do simple arithmetic. It’s very easy to use – it’s just very easy to misuse it as well as normal people don’t think in Reverse Polish.
• My Blue HP is simple for my wife as she just types in the calculation, or for me when I’m learning new techniques as it displays everything on screen. It’s very hard to “misuse” this calculator as it feedbacks everything you’re doing to you, and uses the “standard” mental model of arithmetic.
• My Casio Calculator watch is simple for use on the go; despite the numbers being tiny and a lack of dedicated functions.

 

So the things I’d like to point out from this:

 

• Being hard to misuse generally comes from the systems metaphor matching to users mental model with the minimum of differences (My wife think of 1 + 1 = 2, as does my calculator.)
• Being hard to misuse is helped by copious user feedback – that is useful for keeping people calm that their operation is on track but may not be absolutely necessary (think confirmation screens, double entering passwords, etc)
• Being easy to use generally comes from dispensing with the feedback and cues and exposing only the information the user needs to know (Simple, powerful inputs. Command lines, etc)
• Being easy to use is enhanced by coming up with a different metaphor (Instead of “1 + 1 = 2” you get “1 push 1 +”) whose benefits are only obvious with prolonged usage.
• Easy to use is all about context. What makes my calculator watch easy is the tiny keys and screen which give portability – but in a desktop calculator this would be a major fault.

 

When you get it really right you come up with something that is both Easy to Use and Hard To Misuse. I think Google Mail is a great example. The core metaphor of “tags’ is simple and understandable, but can be very powerful once you work at it. It’s interface gives you a lot of feedback on what’s going on – but in a clear way that guides you through. It provides lots of keyboard shortcuts– whilst giving novice user cues.