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.

Little Change In No Silver Bullet

While I was doing some offering re-read a  classic article that I remembered from my old battered copy of mythical man month called “No Silver Bullet”.

What it drove home to me was how absolutely central the work we do as BAs is to the value that IT delivers to an organisation, regardless of whether it’s always visible. It’s an old article (1987) but still as valid as the day it was written.

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

What struck me most was how little the fundamental problems of building solutions have really changed. 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.”

What we do is probably the hardest part of the solution development process, and the part that adds the most value. If the PM, Arch, and implementers all do their job fantastically then the best result is that the solution is on budget and on time. If we do our job well then the system that we deliver can make 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.

  

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.

Setting Scope in Dimensions

Scope definition is the most contentious, and most useful, of a BAs tasks early in a project. It's a key part of mitigating the project's risks by promoting consensus on aims.

 

Personally I'm most happy when I can promote disagreements over scope within a project. Too often people are using the same language to say two different things, and do not realise there's been a disagreement until too late. A disagreement is proof that I've been successful in bringing this misunderstanding to the surface early, so it can be dealt with during initiation instead of implementation.

 

My favourite way of doing this is by describing scope in three chunks:

• In-Scope: My responsibilities as a project
• Out-Of-Scope: Things that will not be delivered or considered
• Dependent-Scope: Other people's responsibilities, that my project relies on

 

Out-Of-Scope is In-Mind

 

The best way do this is in the out-of-scope section. It's really the only scope section worth mentioning. Seeing a chunk of scope as explicitly out is much more confronting than it not being explicitly included. It's for wishful thinking to take over, and for stakeholders to see what they want "in-scope" if something related is also there, the out-of-scope section removes this false comfort.

 

In Your Scope is Out Of Mine

 

Dependencies on other projects should also go in the scope section. Theses are essentially things your project will not deliver, but is expecting others to do. Inviting the responsible parties from these projects to sign-off on your scope is an opportunity to get disagreements sorted early. Nothing focuses the mind like having to put pen-to-paper on a document that explicitly says what you are responsible for.

 

Multi-Dimensional

 

Explicitly structuring your scope statements around which 'dimension' of scope they refer to can make your scope clearer, encourage you to think about the projects in different ways, and make a point unavoidable by restating it from three or four different angles.

 

Each "dimension" of scope is a single narrow class of items that may be in or out of scope. I've listed a partial brain-dump of the dimensions you could use below.

• Problem: User issues to address or ignore
• Functional: User facing features that are included or excluded
• Non-Functional Requirements: All non-functional requirements can be part of scope, either as area we are targetting to improve, or where we make no promises. (Note that I'm a big fan of phrasing these as negative NFRs - things we can do without is what drives intelligent compromise.)
• System: Which technical systems we are responsible for, or will not change
• Interfaces: System interfaces or integrations that we take responsibility for changing, or normally rely on others for
• Activity: User activity or tasks considered, or ignored (Useful as part of a process when you highlight activities to automate or stay manual)
• Users/Customers: Which user bases are considered, and which excluded
• Organisational: Parts of the organisation whose issues and needs are in scope - very useful when deciding stakeholder and interview lists.
• Legislative: Which parts of law are to be complied with, or whose compliance is a main point of the program
• Deliverables: What documents, sing-offs, or artefacts are included
• Detail: How much details (Descriptive vs Prescriptive) will be included
• Supporting: Which activities or systems will be able to function based on our delvierables. This one's quite useful to say you will produce just-enough to support a particular activity or example (say, estimation) but not enough for another (say, full-build)

Logo for Android

I am really enjoying having Logo on my phone. Making that little turtle run around takes me back to first learning about variables and sub-routines on an Apple ][e. Good times.

 

This is almost definitely my geekiest post ever.

---

This message and any attachment is confidential and may be privileged or otherwise protected from disclosure. You should immediately delete the message if you are not the intended recipient. If you have received this email by mistake please delete it from your system; you should not copy the message or disclose its content to anyone.

This electronic communication may contain general financial product advice but should not be relied upon or construed as a recommendation of any financial product. The information has been prepared without taking into account your objectives, financial situation or needs. You should consider the Product Disclosure Statement relating to the financial product and consult your financial adviser before making a decision about whether to acquire, hold or dispose of a financial product.

For further details on the financial product please go to http://www.bt.com.au/general/rse.asp

Past performance is not a reliable indicator of future performance.