The Benefits of Disruptive Incompetence

In my first job after graduation, I had a boss with no formal qualifications who had not only a technical flair, but the leadership skills to share a vision & make people follow. He was also very opinionated. I remember him once saying of the engineer that oversaw the draughting office that he should be promoted or fired, on the basis that he was doing nothing where he was.  Anytime that engineer visited our project team, we'd smile, accept his latest 'brilliant' idea, & wait until he left before we pulled it apart & did something better.

However, I suspect that, without that bad idea, we would have continued on along a steady path of acceptance that what we'd been given was good enough. We knew it wasn't, so we did it ourselves to prove a point.

Disruption is good.

I don't say that lightly. Not distraction, disruption. A change in requirements often makes you rework the solution. Knowing that there are always changes to requirements makes you rethink your approach to making a solution. That's rarely going to make a worse solution. It makes you, the team, the deliverable, the process of development, all more resilient, both in terms of the deliverable & the quality of the artefacts.

Way back in the 1960s, IBM was a powerhouse of thinkers. Not just that, they delivered some extraordinary ahead-of-the-curve hardware. They did it by working through the night, being over budget, getting burnt out, & basically doing everything we are told good project management avoids. It is a well known fact that, since the introduction of good project management, IBM has produced nothing close to that kind of innovation.

When a bunch of middle-aged white guys got together to define Agile, a new way of working in software development, their aim, was to get a team to a point where it was working at peak efficiency for as long as possible, which usually means achieving a steady state: knowing what you can produce, committing to that, then delivering. Changes in requirements, etc, will always mean changes to either the deliverable or the timeline, because the steady state allows for no third option, where everyone puts their personal life aside & the project succeeds or fails by the original expectation.

Morality gets in the way of innovation. Social responsibility is not compatible with wonder.

Now, I'm trying to avoid saying that I want to force a team, or be part of a team, to over-commit & then burn out trying to deliver the impossible. I don't want that. Any honest executive does.

However, what works is the bit of grit on which the pearl is formed, the itch that keeps you scratching until you come up with the idea of flea powder (or bathe), the idiot who keeps interrupting your flow to ask 'hey, have you thought about this idea?'. Every so often, it's not the idiot's idea, it's their asking that triggers something in the creative genius (common or garden engineer) that sparks a conversation that leads to questioning assumptions that leads to redefining 'correctness' that leads to a late night session where no-one dares to go home unless they miss something that will change the world.

If everyone believes the same things, then no-one will learn anything new. If everyone thinks the same way, then no-one will produce anything new. If everyone agrees, then there can never be anything new.

Disruption is good.

Don't go out there intentionally disrupting everyone & everything, but be more open to the process of disruption.

I worked with an excellent executive once, & we were strategising how to build a brand new team that would create a new product based on a prototype. Selection was based on 60% technical match, 30% team fit, & 10% being a good person. In his experience, you only needed one bastard in the mix, & that was going to be him. Role filled. Move on.

He was the disruption. He was not a technical visionary. He was certainly an excellent leader, but I'd never seen him build anything. He was also a good corporate tactician. That team, which stayed together as is for more than a year, but many of whom remained for several years, backslid to producing mediocre output as soon as he stepped away from the role.

I will admit to my own failing in not being disruptive enough when I stepped in as designated bastard, having designated myself bastard on a different arm of the business in the meantime as a technical person with almost no grasp of market analysis.

Again, I stress that being the disruption is not essential, but being able to recognise the disruption & their role in kicking the project forward - or sideways - is key to delivering surprise & delight to your stakeholders.

The Interview Maturity Model

 A long time ago, the Capability Maturity Model was a thing, & it laid out a framework for how to measure an organisation's 'maturity' - how it had grown as an IT company to be considered 'capable'. I know, that's a lot of rabbits. It was supposed to encourage rogue IT professionals to think about their processes, & for company administrators to set achievable goals that improved the processes. At the highest level, very few companies achieved CMM6, or at least very few would advertise it, & those that did were doing so for bragging rights or were in a competitive market (like consulting).

Today, I am unemployed, which means I'm bored enough to think about interviewing from the receiving side. I've done a lot of interviews from both sides over the years, so I think I'm in a fair position to judge technique as much as assess effectiveness.

I am willing to propose a simple model for gauging the maturity of an interview process. Although I have the IT industry - or IT professionals - in mind, I am sure there is some equivalence that can be extrapolated.

• Level 0 - no process. You interview so rarely that each position is 'unique'. There's nothing wrong with that, but you could invest some time into thinking about the effectiveness.
• Level 1 - a repeatable process. You file an outline of an interview, perhaps with questions related to different roles.
• Level 2 - a delegate-able process. One person holds the process & others implement it. The process can be described simply, but the interviewers must be capable of performing the interview. For example, giving a technical question to an agent requires that the agent be able to understand the answers.
• Level 3 - effective content. The interview questions are reviewed & updated for relevance to roles. This includes querying the candidate's history as provided in the CV. The interview has structure, such as a timeline to minimise the chance of overrun.
• Level 4 - effective interview. The interview process allows for an interviewer to not only find the gaps in the candidate's knowledge, but also find out about the candidate (not just their history) & determine their 'fit' beyond technical skills.
• Level 5 - training, collective accountability, & feedback. Although the process is well-defined, an interviewer can benefit from practice, each interview result is discussed by a group of people involved (rather just reporting their findings), & this reflects both on the candidate & the process itself.

Note, I am not saying that this has to be done in one, two, or ... far too many interviews. I have worked for large companies that spread out the process across five distinct aspects (initial, technical, architectural/communications, management, cultural), or manage to squeeze this down into three. You can turn the technical testing into a take-home exercise, use a group interview, add a final executive (for a senior role), & apply all sorts of variations. That becomes your process.

The main point here is, look at where your process sits, & determine whether it's worth the investment to 'go up a level'.

Why would you?

If, for any reason, you feel that you're not getting the right candidates going through your process - failing at a late stage - or the candidates that become employees fail probation regularly or leave within a year - churn - then this is an unnecessary cost to the business that could be minimised by having better interviews. If you like, having this measurement is Level 6. It's more of a trigger that you need to review, & either you already have a review process, or you can now justify building one.

Retention

Retention rate, at the board level, is a good measure of the effectiveness of the professionals who are producing the goods & services, & may well reflect on that output quality. However, & this is important, it has to be measured as something beyond average tenure of current employees. Churn is a factor, but churn amongst new employees is the best indicator of, for example, a toxic workspace.

If you're attracting the right candidates & employing them, then you also need to measure both their continued fit & their likelihood of staying on. They were employed for a reason - skills-wise - & you don't want to lose those skills or have to replace them, because that costs resources.

But that's another topic entirely.

Empathy for the forgotten

 I just failed a coding test.

A lot of you are thinking "so what?", but here's the thing - it's quite possibly only the second coding test I've ever done, & the last one was 1998 (in C). In the meantime, I've been interviewing dev candidates quite regularly over the years, designing tests, developing ideal solutions in various languages, assessing the great unwashed brought before me.

I just failed a coding test.

Sure, I have some very reasonable excuses. I tried to set up a dev env on my Chromebook & spent so much time configuring the IDE to cope with Typescript that I forgot to actually practise some Typescript, &, oddly, Typescript would have been particularly useful on this occasion, but it had all leaked out of my brain in the process of ensuring that I could indeed run & debug said Typescript if I could actually write it. I can, by the way, along with a wide variety of languages that I have happily worked with over the last 35 years.

The problem is that I am not a <insert language> expert. I can move to a different job, dump the contents of my brain, & be quite comfortable in Chicken, for example, if that's what's required. I don't see problem solving as language-dependent. The programming language is just the tool at hand - like the IDE or the OS. Change one, & it doesn't stop me from working. It does, however, stop me from passing coding tests.

Actually, it only stops me from doing live tests, because if I spend half an hour looking at code to 'get' a language again, then I can do a take-home test easily - I've done that before. I wish I'd remembered this salient fact yesterday. Of course, it didn't help that the very kind interviewer suggested I write pseudo-code or use another language, & I plumped for Kotlin & realised that my IDE didn't have a clue where to go with that, either. I should have done Java, but I was already not thinking straight.

Live tests are supposed to give the interviewer an idea of the candidate's thinking skills & ability to communicate that thinking, rather than mastery of an IDE or even a language. If their approach to coding covers algorithm implementation, data structures, coding style, a nod to testing or test-ability, & an inkling of performance & memory implications, then you're on a winner. If they code that up like a machine, then that's confidence, at least (just check for arrogance).

However, that doesn't relate to the real world. I've just come from a large software company with products & tools & infrastructure & ... stuff. To fix a problem from the field, you analyse, you test (online, in prod or staging), you write more tests to prove your theory of what's wrong, you implement a code change to fix the problem, you write tests based on your implementation, then test online before getting peer review & such. New features only differ slightly. There's very little greenfielding where someone says "Here's a brand new problem, & I want you to start with an empty code project". Even new products & services start with a pattern, whether it's a microservice template, a plugin for the product, or a base line of configurability copied from the last such module.

Only twice in my career has someone said "Start with nothing; assume nothing". Both became patentable.

Professional developers don't get to write little algorithms in isolation from scratch. I actually think they should do it more often, though, because that's the basis of TDD & unit testing. Write an algorithm, prove it, then plug it into the code base. No-one does that, because of things like dependencies. There's a whole raft of 'stuff' that you need before you can prove that algorithm - like a test infrastructure, JSON manipulation, HTTP client or server implementations - that's already in the project. It's not laziness that makes you shy away from creating a new Maven/Gradle build to then immediately throw away, it's efficiency. I've done something like that a few times - do the work in an existing project, then copy the whole thing & pare it back to what I need as the new project.

I'll tell you who is good at writing one-off, independent, no-strings solutions to small problems: undergrads. In theory, they should be the perfect candidates to fly through live coding tests, because that's how they've been taught to code. Well, it's how I remember teaching them in the 1990s. Now, those students are, like me, giving coding tests to candidates with the belief that it's simple to pass the test themselves.

I'd like to think there's a way forward here. 

The first point is to ensure that a coding test is not simply a verification that what someone says in their resume is accurate (never assume it's a lie, either). A coding test, like any interview, is an opportunity for the interviewer to get to know the interviewee & determine the fit for the role, the company, the future. I'm not saying that the code itself is irrelevant, but it's a part of the interviewing process, not a box to tick, a criteria to match. It shouldn't be a trick question that proves how clever the interviewer is, either, because, as always, the interview has to run both ways. You, as interviewer, are being judged as a representative of your organisation.

The second point is that live coding tests only work for someone who is comfortable with that exact process, so nerves, brain-freezes, distractions (like illness), are all a part of that experience. If someone can do an offline test beautifully, then an online is useful if you're looking for someone to pair-program, for example, but not necessarily for someone to work remotely or in isolation. 

Most importantly, empathise with the candidate. You don't have to make allowances for their lack of social skills or inability to perform under pressure. That's called being human. If you can alleviate the symptoms, that's under your control, because you're in the dominant role in the conversation. Just don't make things worse by judging performance under unusual circumstances as indicative of how someone can actually perform their job - at least hold that back until you write up the review.

I just failed a coding test.

I'm human. You're human. Let's interview humans like humans should.

You've Got to Have Faith

(With apologies in memoriam to George Michael.)

I've been working through a consultancy firm recently where the CEO (I'll call him John) wanted to create a Christian organisation because he felt most comfortable dealing with people with whom he had some basis of understanding in how to go about doing business - a set of ethics, if you like.
John & I would have great discussions about everything - even work. Most importantly, though, because of our shared beliefs & the trust that we could easily build from that, the conversations were often more open than one might usually have with a colleague because "I would like to talk about something that must remain between us" actually meant something to both of us.

This is not a mutual understanding of dissembling, but trust based on acceptance of who we were as co-practitioners of a religion with a set of values we both understood & believed in. This is not a matter of two people of the same cultural background (which we may be for one generation) seeing eye to eye, but a conscious decision on both our parts to recognise the commonality & embrace the faith within ourselves for the other.

This is empowering. It is an uplifting experience. It meant that we could bring up topics that skirted "taboo" in a professional relationship & find our way through them. Then, we would each feel good about the conversation afterward - no awkwardness.

While on the client site, one of my closest working relationships was with Ali, a practicing Muslim (some of my relatives are Muslim, but they don't practice, so I know the difference).  Ali & I may not have discussed much beyond work, but we instantly understood each other to be ethically equivalent as people who had a faith & could be trusted to follow a set of moral guidelines.
We got along very well. We may not have always agreed in some of the procedures each of us had to follow, but we would trust each other to do so without question - or else apologise profusely for the oversight.

This is how people with an ethical code work together. They don't need to second guess. They don't fear upsetting someone accidentally. They don't hide their own failures or highlight other's. They don't undermine or expect praise. People who trust each other in the workplace get the job done together out of joy, out of commitment to each other & their shared cause, out of a belief that everyone else is doing their best to get the job done - which is different from not letting the side down.

This post may seem to be far too religious for the workplace, & it may not be easy to implement ethics in a workplace where people are antagonistic towards religion in general, but the simple fact remains that trust - between co-workers or between managers & their reports - is fundamental to both a healthy workplace & delivering projects.
Religion - the existence of any religion - is a relatively easy basis for trust, as long as it encompasses everyone. Otherwise, you have to build up another ethical construct that is inclusive, easily embraced & understood, & consistently applied. That's a tough ask.

Supermarket Software

My wife bought a custard scroll for my Saturday breakfast. I was really looking forward to eating it, but when morning came & I sat down to devour its bready-custardy goodness with my coffee, I was sorely disappointed. It had come from the supermarket, not a bakery. It had the semblance of a custard scroll, & was packaged attractively, but it was all wrong. It reminded me of the last time I bought an umbrella from a supermarket - it let me down in the first rainfall.

I fear that we too often write software just like that. We might be getting better at building & deploying, but the software quality is falling down.
One of the side-effects of agile & lean is that fast-paced often gets interpreted as cutting corners. That's simply not the intent.
Another side-effect is that if you only build what you need to satisfy the requirements, then you'd better make sure that you articulate your requirements thoroughly - & then align them with what gets created, through demo & review.

I don't think there's anyone in the supermarket who is taste-testing scrolls or opening umbrellas. They're in the business of selling stuff, not providing a quality service.
This is why we shouldn't be treating software development in that way - software is a service to your business or else your customers.
It shouldn't have designed obsolescence unless that is a specific requirement; & yet too many people build that "feature" in but saying "it will never need to do ..." without actually thinking about the use of the software. In fact, software developers don't really know what the software might be used for, & have to hold themselves back from thinking of code re-use.
Product managers are the experts, using their knowledge of the market, their audience testing, etc.

Software shouldn't go onto the supermarket shelf (be deployed) unless the product manager has tasted it & is happy with the flavour & texture & utility of the software product. I'm not just talking about BAs & testers performing another series of processes that follow the requirements, but that higher level of understanding of what the software is meant to do, relative to its consumer base.

Sometimes, we fall back on the waterfall approach & say "well, that's what you asked for, & it's too late to change", or "that's all we have the budget to deliver". In effect, you're just selling those umbrellas that only open once. It's definitely not agile.
It hurts the company's reputation & bottom line, if you're talking about a product, & it hurts the business unit's ability to deliver anything in the future, even if it's an internal release of services.

A CEO from my past once used to say "we don't have to build the Rolls Royce".
He was right - we need to build the Beetle - the product that everyone was happy to use, was reliable, & targeted at its audience. Behind the scenes, German manufacturing's precision & quality was legendary - & very successful.

We, as software developers (& I include the whole development process here) have the responsibility to work like a bakery - taking care of each masterpiece we create - rather than like a supermarket pumping out software-like things in neat packages because it's cheap to do so.
A good bakery never goes out of business. A supermarket often has to heavily discount its unsold product.

Story Cost & Story Value

I read a complaint recently along the lines of "why do we still fill in timesheets?" There was a lot of opinion from the conservative "that's how project accounting works" to the radical "we don't need them". Somewhere in the middle, timesheets are relevant, useful, & painless.
These three things are not the same, & people too often try to fulfill only one aspect.

Timesheets are useful when they reflect the reporting needs. However, if you're not reporting on the actual activity, then there is a disconnect. Either, you have to change what you are reporting, or you have to accept that the data you are reporting with is not real. That's a disconnect - & a sad fact.

Timesheets are painless when they can be done "automatically" as part of an existing process - preferably without the team member doing anything. This could be as simple as monitoring their keystrokes (big brother = no bother), but it is better if the team are clocking all of their time against tasks in an issue management system - & every activity must be in the system.

This allows you to perform reporting against what is really happening, as opposed what is supposed to be happening. This is relevance.

There are plenty of tools out there to do this type of tracking, & none of them have the word "timesheet" in them.

They do, however, all track time in minutes & hours. In modern agile processes, activities are not estimated in time, but in story points, & they are often prioritised by business value. Therefore, there is a cost - estimated effort - against each piece of functionality that provides business value. In a lean environment, if there is no business value, just don't do the task.
We use this estimated cost in planning. We also use measures like velocity to determine scheduling: the number of story points - & therefore value - that the team as a whole can produce within a sprint (a time period).

We seem to have most of the elements in place to estimate a financial cost for each unit of business value that is delivered as long as we can determine a tangible correlation between delivered functionality & ROI - in terms of market share, increased sales, the value of the IP, or share price.

How can we define that true value of each feature?

Look at the approach taken to determine story points - it comes from experience. The team - the experts who are doing the work & have been doing it - agree upon the most likely cost, using tools like planning poker & the team velocity. They rely on the fact that, over time, estimations even out & have lower variance through increased skill & practice. Most importantly, they don't estimate in man-days. Still, tracking in hours, & having two-week sprints, "works".

The equivalent must be true of business value points - looking back over what impact a feature has on the value of past releases of product, plus the appetite in the market (based on end-user interviews, A/B testing, prototyping, etc), a relative score (not dollars) could be developed that would vastly improve the input to planning product development & this would also contribute to the accountability of the process in a much more tangible way than timesheets that track activities.

Pass the (Open) Source

I have been slightly freaked out recently by the extremely positive feedback I've been getting around a project I've been working on that is based heavily on an open source solution.

I've been down the open source path many times before - almost exclusively as a consumer or indirect contributor (offering suggestions to the project owners) - but not as a contributor with a major enhancement, say. It's just never happened. Most open source "does enough" for what I want to do as is.

At first I was intrigued that my manager showed such excitement that I could take something effectively free & get it to a point where it was actually useful for the project. As I said, I've used enough projects before to expect a non-perfect solution, but usually something viable comes up.

Then, she started getting excited with the idea of me sharing my experiences with other teams to encourage them to think in terms of not just using open source, but doing so with the intention of contributing back to those projects from the outset.

Again, not that radical from my perspective ... until she explained that the company - a financial services giant in the market - never thinks of open source as an option, let alone thinks of being a part of the community of dedicated IT professionals who spend their spare time, or else contribute from their company's development time, to make stuff for other people to just find & use as they see fit.

Admittedly, there are two very different software worlds out there - vendor world, & open source world (plus some blurry bits in the middle). Those two worlds only differ in their attitude towards licensing, not in their attitude towards quality.

In fact, there is a massive industry out there effectively being the consulting services, bespoke development or customisation, or support arms of open source projects. These people are an important part of that open source community because they get direct customer feedback on what makes better product (as opposed what sells better). They drive the development in the same way that vendor product is developed from marketing strategy & product leadership.

Yet many service sectors that rely on IT professionals to provide infrastructure (in financial services, telecoms, utilities) "feel more secure" out-housing the mitigation of their technology risk to the very people providing the technology, that is, through licensing & maintenance agreements.

Once upon a time, banks in particular used to have massive in-house development creating bespoke solutions that worked exactly the way they needed. That's out of favour. What's in favour is getting in the same consultants as the competition did to build something sufficiently different .

I know that my company is not one-hundred-per-cent happy with that arrangement. Very few companies are. I can name very few enterprise solutions that "just work" to the point that you can believe the marketing hype.

So, now's the chance to try something different. Start small & look to see if there is a way to introduce open source solutions into a project - cost it out in terms of support. If that works for you, try enhancing an open source project & contributing to the open source community to become an influencer of the development of such solutions, rather than just a consumer.

The "cost" of transforming thinking may be less than you think. The benefits may be more than simply financial. The end goal is to be able to provide a better service to your customers by owning more of the knowledge around the service & being able to make your service better under your own control.