Capturing Requirements – A How To Guide. Part 1: What do you mean I have to talk to people (in which I largely avoid talking about the topic)? – Obvious Code

Capturing Requirements – A How To Guide. Part 1: What do you mean I have to talk to people (in which I largely avoid talking about the topic)?

It’s a common cliche that us techies can be socially challenged.

This is a cliche

I’ve long disliked the comic above, it’s patronising, it’s out of date, it’s offensive, and most of all it panders to a stereotype that I now feel an onus to challenge by becoming a better communicator, which means talking to people – icky, messy, complicated and illogical people like users, people who have needs and requirements and don’t appreciate the wonder and beauty of my code.

The costing rules need updating? That’s awesome, because I have a brilliant IOC pattern at the base classes of the rates engine, employing a Strategy Pattern with some really cool Reflection that means I only have to write five lines of … will you please stop looking at your phone whilst I’m trying to tell you what a great developer I am

Okay, okay, enough pandering to the very stereotype I am trying to challenge, but the point is, there may be a grain of truth in this cliche. Whilst there are those Renaissance Developers out there, who can feel equally at home in sales, design or management (sickeningly talented people, many of whom have the added temerity of also being extremely likable) – when it comes to interpersonal skills many of us fall short, especially at the beginning of our careers.

And that’s OK.

We became developers, generally, because we liked the challenges, puzzles and logical beauty of coding – a deeply personal endeavour, and one that largely takes place in the ivory tower of our own heads. Code gestates in our creativity, before it even touches the ephemeral medium of the IDE. It is then transiently displayed in pixelated Unicode representation so we may further refine our creation – sanding out the bugs, playing with the grain of the data flow to build form, structure and the occasional whimsy.

It is then scanned by an electronic Golem, one that we possibly have but a rudimentary understanding of, however fondly call The Compiler. Our ambiguity is bemoaned, our logical errors are refused and thrown back at us, but eventually, it is transformed into an even purer form of logic, a complex and arcane language, the true code, that only that impersonal cyborg, the CPU, can ever truly know.

Our code is crafted, then it’s compiled and consumed by technology. It’s a very inward facing skill, almost a form of meditation and that’s beautiful.

The problem is that code is not there to fulfill our yearnings for flow state and Zen, it’s there to build stuff. Stuff that people use. Real people, people with proper jobs, useful important jobs that have an impact on the real world – paying people, delivering things, educating kids, and all sorts of other interesting (or boring) tasks, that you may not even have known needed to be performed. As a rule, these sort of people care about your code only as far as your code will deliver them the product and experience that they paid for.

And it is a certainty in your life as a developer that, sooner or later, it will be your job to deal with them.

Story Time 

(I will neither confirm or deny any of this happened at any company I may mention in my bio)

Once Upon a Time, I used to work for a large US software company, my role, a “Technical Consultant”. In this company, Sales People made a lot of money by speaking to Business People, convinced them to buy our software and services, had Finance and Legal People write up some documents, which, in turn, would prompt Senior Technical People to “Nut out a Spec”. I would then have meetings with Project Manager People who would have attended their own meetings and skimmed the above spec, and then (usually poorly) explain the project to me.

Next, I would go to an office in the city somewhere to “Implement a Solution”.

After some time, anywhere from a few days to a few months of meetings, coding, configuration, late nights, yelling, drinking, crying and blame shifting, the project would then be signed off. Occasionally the client would even be happy.

Then, one day, during the end of the Era they called Dotcom Boom, a dark cloud fell over the land, and a great bemoaning was heard as the empire was plunged into hardship, and people were brought to reckoning. Many of these people were sent into exile from the company, and a few of the High Lords were cast into the dungeon (for *ahem* dodgy financial habits), but most importantly (for me at least) my team was cast into the Depths of Hell and “Merged With Pre-Sales”.

We were very strongly assured, in a very convincing tone of voice, that joining sales wouldn’t mean we’d have actual sales quotas to fulfill – which only meant that we were being judged by something far more ethereal than actual figures, rather the whims of the various sociopaths we called Sales Management (allegedly allegedly allegedly).

We were given hours upon hours of training, most of it over unpaid weekends, learning to identify pain points, up sell solutions, practice 10 second elevator pitches and take long, hot, showers at the end of it all to scrub away the filth. But, after it all, it became all to obvious that us techies sucked at selling.

Not strictly true, I admit, a few of us excelled at it – I even won an early model iPod for ‘up-selling’ a solution (in reality, the client had approached me to ask for a real Sales Person, but I took the prize nonetheless), but as a rule, we were generally more of a hindrance than a help.

I recall, as an example, an important sales presentation that I had been flown thousands of kilometers to attend, where I regaled the Upper Management of a very large transport company with the subtle pleasures of Metadata Repository Scanners as a way of identifying Logical to Physical Model connections by way of a lexically parsed, and frankly, even to me, obtuse and arbitrary mapping file (and, as an added bonus, I then got to watch the poor Sales Person try to recover the demonstration, by attempting to wake the attendees with the – completely blatant lie, and line stolen from IBM marketing – assurance that no one was ever fired for purchasing our software).

Now, this left the company in a bit of a bind. They needed us techies to do the actual work, the stuff that actually got them paid, and they had got rid of as many of us as they felt comfortable doing – but, top heavy a structure as they were, at a financial level, they were desperately trying to justify keeping us on the books. They briefly flirted a with Indian Code shops, but that’s a story unto itself.

At this point, they actually did something incredibly cynical. They promoted every single member of the technical staff to the level of Software Architect – a decision that had three immediate, and tangible, benefits for the company.

First, this change was judiciously timed to ensure that any meager pay rise associated with the title boost was delayed as far as possible into the future.

Secondly, they could now bill us out at much higher rates that before – although how they could justify charging for three Software Architects on a project as opposed to the 1 senior consultant and 2 replaceable peons is beyond me.

Finally, it doubled the work load of everyone for free – as now we all had to ‘Nut Out Specs’ as well as ‘Implement the Solution’. As workloads were doubled, the team could be halved, and more of our team were released in to the wild. Redundancy packages would need to be paid, for sure, but that was a one off expense.

To their credit, however, this move did not come without benefit, and, over the course of yet another unpaid weekend, we were all given a crash course in Solution Specification and Design. We were taught an out of date version of UML, given a 4 MB USB stick (a remarkable amount of portable memory at the time) and two boiler plate documents, that were to form the basis of all design documentation for the following years. They may still be using these documents, they certainly were when I left a few years later.

What they didn’t teach us, however, was any of the softer skills of client interaction – we were still being seen as autistic code monkeys, unfortunately overpaid workers, who needed to be pointed at a sale to perform our magic. Sales and management were the human faces of our company, and we were just the paid labour, the corporate equivalence of the tradie who installs your double glazing, after the suit in the show room, with the new car and shiny teeth has schmoozed you through sales process, and steered you towards the contract. We were still the dirty, oily, end of the deal, who needed to be shielded from the view of the client where ever possible.

The worst thing about this all, is that we bought into it, just as much as the rest of the company did.

Frankly, we were happy to be protected from the unpredictable reality of client interaction – true, we eventually had to talk to them, deal with them, on site, and at times, it was very pleasant, but it was a forced sociability. What it wasn’t, however, was a professional relationship, at least not at first. In those days our company was dealing largely in finance and large retail, banks, stock exchanges, production distributors – huge corporate structures that mirrored ours. Dealing directly with the client regarding a project, without the guiding hand of management, was discouraged from both ends. The Boiler Plate document was king, and that is what we stuck with, whether that document was correct or not. The needs of the client were ignored. All problems could be used to leverage further sales in the future, and that was just the nature of the jungle.

That was the early millennium, and thankfully things have changed. The role of developer has changed a lot since this time, as have the methodologies around project design and implementation.

These days, even if your role does not directly require face to face client time, the ability to communicate in a meaningful way about project related details, be they requirements, design, implementation details, testing, bugs or change requests, should be a viewed as an important component of your skill set. If it’s one you don’t feel comfortable with, don’t worry, it’s a skill and it can be improved. I’m not suggesting you’ll end up a Sales Person, just a better developer.

I will get around to concentrating on this topic in my next post, though I don’t promise to stop rambling – this reminiscence is just too much fun.

Leave a Reply

Your email address will not be published. Required fields are marked *