High functioning autistics don’t work in vacuums
I had the pleasure of recently listening to one of the most entertaining podcasts I have heard in a while where Scott Bellware was the guest in question. Scott is a captivating speaker and always prompts you to challenge your own beliefs and ideas as a developer. The podcast was intended to be centred around a discussion on BDD however Scott points out that he practices “Context Specification” and that it differs somewhat to BDD.
Something that has stayed with me in the weeks passed since listening the to discussion, is Scott’s description of developers as ‘high functioning autistics’. The context in which Scott makes the observation is one where he expresses a desire for developers to speak more fluently in the language of the business and desist in articulating implementation details or information of no business value. I’m sure that most people will find that idea logical and reasonable (as I do) however I feel that it’s worth throwing some attention onto the business and how it communicates in the reverse direction.
Any relationships success relies on the mutual respect and determination of all parties to participate in functioning cohesively to achieve a common goal. Yes developers should aim to achieve communicating more effectively with the business but it should be said that business people must take an equal position of responsibility for the success of communication between the parties. I’m pretty sure that most developers have worked in environments with little structure or discipline, where ad-hoc is the methodology of the day and expectations are generally unreasonable. I am sorry to say that I have seen developers purposefully communicate in an abstract way with business people, in an attempt to shield themselves from the kind of environment I just described.
I find it curious that we even speak of ‘developers’ and the ‘business’ as separate entities almost as though they exist in different dimensions; surely we developers work for the very same business as do those in HR, Sales or Warehousing? By definition we must also be considered part of the business. Seriously though, I understand the distinction when we speak about ‘software’ and the ‘business’ in terms that express a notion of separation, but I guess I am starting to think that it’s a consequence of the inadequacy of language that helps in promoting exactly some of the problems that Scott wants to see eradicated.
I think it’s worth making the observation that whilst developers should take responsibility for themselves in communicating more effectively across the organisation they serve, it’s incumbent on all parties to create environments designed for successful communication that travels in all directions. There have been plenty of occasions where I have seen ‘business people’ behave in a fashion that demonstrated a lack of respect and understanding of those sitting on the IT side of the fence. Respect is a two way street.
2 Comments so far
Leave a reply









There’s no doubt that respect is a two way street, but as hard as it is to swallow, we have to tke a good hard look at the conditions that led to the separation of business and IT and consider the psychologies that exasperate and perpetuate it.
Programmers have a difficult hurdle to get over. It’s a problem of not being aware of not being aware. Programmers are deeper into their own, single-minded, communicative isolation than they recognize. Just how far programmers have gone down this rat hole doesn’t leave a whole lot of room for dialog about the things that come of this situation, like expressions of lack of respect, for example.
The problem might be worse than you think. And if you’re a programmer and you can’t see this forest for the trees, it’s even worse than that.
The issue of programmer autism isn’t just an issue of communicating with non-programmers, it’s all of the lack of awareness communication necessity between programmers. The amount of productivity just thrown away because programmers don’t consider the user experience of their code is unconscionable. And yet, programmers are barely conscious of it and often closed to just how far they have to come to break the habit of the cop outs and excuses made for code that has to have meaning and understanding beaten from it versus code whose meaning and understanding flows from it at a glance.
That programmers fundamentally don’t understand the imperatives of user experience and user interaction, and yet continue to assert acumen with user experience and user interaction is an enduring testament to the problem.
The industry was able to wrest influence of experience and interaction design for user interfaces from the hands of programmers, but code will remain the sole domain of programmers. We’re getting more and more isolation than we asked for, making it ever harder to rehabilitate our cast of characters. And it’s no less difficult in the face of all of the excuses that programmers continue to make in regards to entitlement to cognitive isolation and the perpetuation of cultures and communities commiserating in isolation.
[Reply]
Scott
The problem of ‘not being aware of not being aware’ is indeed a large hurdle as you remarked. I have had the privilege of having experienced three careers over three very different industries (fashion, music and IT) and have observed this phenomenon of the awareness bereft from three very different aspects. It’s prevalent amongst all walks of life in all centers of industry.
I for one will embrace any tools, methods or mindset that brings me closer to the business that I am aligned with. And I certainly don’t want to be construed as making excuses for our profession where there is no longer any scope to do so, however my experiences have me willing to consider that along with the explosion of IT and Software Development teams within businesses of all types and sizes, the challenge also remains for many businesses to conquer their own issues of sophistication with respect to this ongoing and (for now) essential relationship.
In the meantime, BDD and Context Specification certainly offer us potentially wonderful opportunities for addressing how to start better upholding our end of the bargain.
[Reply]