People, by and large, work by trying to achieve goals - and it is by understanding their goals that we can best understand their behaviour. That is why "user stories" are such an effective way of capturing requirements (most approaches to requirements capture are effective when they are used with a focus on what is being attempted). But, as anyone that has done requirements capture should be able to tell you, people tend to be poor at explaining what their goals are. Without guidance they will focus on how they expect these goals to be achieved.
Contrast the following directions to a colleague's desk:
"Go through those double doors, across the office and through the next ones, down the stairs to the next floor, turn left and go through the security door, follow the corridor around to the left and right, when you go through the next door he's over to the right by the window."
With:
"About twenty feet in that direction and one floor down."
Which is easier to understand? Or easier to implement? I'd take the goal oriented version - which tells me where I'm trying to get to - every time.
More importantly, the first explanation is much more susceptible to changes in circumstances: the stairs being out of use, extra doors being introduced on the corridor...
A couple of years ago I spent several months working with business analysts who regularly produced requirements specification documents that read like the first quote above. Actually, they were worse: although the business analysts avowed no special knowledge of computers, and especially of user interface design, they included screen layouts. I was involved for several reasons, but two important ones were that the customer didn't accept the resulting software (it didn't address their requirements) and that the requirements capture process was far too slow (at the rate it was going it would take several times the agreed time-scale for the project).
It didn't take long to establish that the business analysts didn't enjoy writing this stuff. Or that the customers struggled to approve it (or "accepted it" without agreeing for contractual purposes). Or that errors and omissions were not detected until late in the development cycle (integration testing or acceptance testing). Or that the developers were frustrated into blindly implementing things they didn't pretend to understand. And if a change in understanding required changes to the product it was an intractable problem to find all the documents affected.
Fortunately, by the time I got involved, the project was suffering sufficient pain that enough people were willing to try something else (so long as I took the blame if it didn't work). Having quickly read Cockburn's " Writing Effective Use Cases " I chose to introduce goal oriented "stories" describing what people would be doing with the system we were developing. We also dispensed with screen layouts and substituted lists of items to be input and presented. The customers found the resulting documents more accessible and contributed more to their creation, the business analysts found the documents easier to produce, and the developers felt they could identify and deliver what was wanted. Everyone thought it an improvement.
Why then had the "old way" become established? Asking the business analysts got responses along the lines of "we don't like it, but that is what they [the developers] want". The developers had a different version "we don't like it, but they [the business analysts] have to do it that way for customer sign off". Somehow, no one had been happy, but had just accepted that things were the way they were because "they" needed it that way.
"They" is one of those stereotypes of social life - a faceless other that behaves in inexplicable (and often damaging) ways. Users try to do the weirdest things with the software we supply them, managers seem determined to stop the work getting done, prospective employers eliminate talented individuals during the recruitment process, developers show no interest in avoiding problems, accountants shut down successful projects. "They" cause many of the problems and irritations we face in life. "They" are stupid, malicious or ignorant.
Nonsense! If you can find and talk to them you will find that "they" are normal human beings trying to achieve reasonable goals in reasonable ways. And, all too frequently, "they" are just as dissatisfied with the state of affairs as you are.
-
When I'm using a piece of software I don't suddenly lose all sense - maybe it is hard to figure out how to achieve my objectives. I'll try things that make sense to me to try - which is not always what the developer expected. (Even when the developer has been diligent about getting feedback on the user interface design.)
-
If I'm running a project then I don't forget that code needs to be written, but sometimes ensuring that the functionality meets the need or ensuring that funding continues requires something else gets done first.
-
If I'm recruiting I need to avoid people that won't be effective in the organisation - bringing someone disruptive into a team costs their time and that of others. Given that cost is it surprising that employers are not prepared to "take a chance" when there is anything that raises doubts about the suitability of a candidate.
-
If I'm developing software I can only tackle so many issues at once. If an organisation lacks a repeatable build process and version control then these are things that need fixing before looking at the proposed list of new features. Some problems are not serious enough to warrant effort right now.
-
If I'm funding work I want to see a return (not necessarily financial) that is better than alternative uses of those funds. The way in which software developers sometimes report results can make it very hard to assess that return.
I don't consider any of these goals inexplicable or unreasonable - nor should you.
It is a refusal to consider the reasons for the way "they" act that builds the problems, and labelling them "they" is an abdication of rationality. While there is a role for "they" and "we" in thinking it is one that defines allegiances and trust, not one that helps to resolve problems.
Some of this thinking seems to influence the content of Overload: many potential authors think that "they" (the editorial team) are only interested in C++, while the editorial team wonder why "they" (the authors) hardly ever submit material relating to other languages. Admittedly we do get a few Java articles, but where are the C, Python, C# and SmallTalk articles? I know there are members that are interested in these technologies, so there should be both an audience and people with the knowledge to write something. Come to think of it, if you think "they" are not publishing the right articles why not get involved? You could write articles, you could even join the team - we've not recruited any "new blood" to the Overload team for two years now. Maybe "they" could include you?
ACCU Certification
As I'm writing this a discussion has sprung up on accu-general about a topic that resurfaces every year or so: "why is there no effective qualification for software developers?" There are organisations (like the BCS, IEE or EC[UK]) that might be thought suitable for supporting such - but "they" don't provide anything the list members feel is appropriate. This same issue was raised in Neil Martin's keynote at the last ACCU conference when he suggested that the ACCU step in and address this need. As a result, the ACCU Chair (Ewan Milne) asked me to arrange a "Birds of a Feather" session for those interested in exploring this possibility, and to represent the committee there. The session was well attended, and there seemed to be a strong consensus that there were potential benefits for both developers and employers in some sort of certification-of-competence scheme. It was also thought that it would be a good idea for ACCU to get involved in producing such a scheme. Questions were raised about what was involved in becoming a certificating body, what it was practical to certify and what the mechanism for certification might be. There seemed to be a lot of interest - so Neil promised to research the certification issues and I took email addresses for those interested in participating in further discussion and got the accu-certification mailing list set up.
Clearly there was a misunderstanding: I expected "they" (the people that signed up) would involve themselves in doing something. It seems that those that signed up expected that a different "they" (Neil, myself or the committee) would do something. In practice only Neil did something - he reported back as promised: ACCU could reasonably easily get itself recognised as a "certification body" for this purpose. The details of what is involved were circulated via the mailing list. And that was the end of it until the discussion on accu-general .
It is easy to be critical and say that "they" should do something. In this case that "they" (the ACCU) should do something about certifying developers as being competent. But just think for a moment: you are a member of ACCU, and ACCU works through members volunteering to do things. So you are one of this particular "they", and you know exactly why "they" are doing nothing - because you are doing it yourself.
In practice though, I feel that the ACCU already does provide a useful qualification: I did hundreds of "technical assessments" for a client last year - most candidates failed in ways that gives cause for concern about an industry that employs them. (Interestingly I had feedback both from the group that I was working with about how competently the "passes" fitted in and also from other groups in the client organisation that decided to employ some of those I had failed at interview - and then found them deficient.) The qualification that ACCU provides? I can't recall any candidates that mentioned the ACCU on their CV failing the technical part of the process (while the client wasn't prepared to exempt them from the assessment on that basis, the manager selecting the candidates to interview noticed this).
Before you go
I was very pleased with the feedback on accu-general and elsewhere to the report by Asproni, Fedotov and Fernandez on introducing agile methods to their organisation (I'd spent some time persuading them to write this material up). As a result I reviewed some material that Tom Gilb had passed me at an Extreme Tuesday Club meeting last year looking for things that might interest Overload readers. Amongst this material was a couple of articles (Jensen and Johansen) that appear in this issue by kind permission of their authors. I hope that these too meet with your approval.
