I was reminded today of the value of debate, strongly held opinions and having the courage to let go of weakly held opinions. I like to think of the latter of these three as the ability to liberally contradict oneself when it becomes clear that a position held no longer seems able to be supported and the only logical course is accepting another point of view which has stood up to the rigours or test of the debate.
The best experiences I have had always seem to take root in groups (even as small as two) where debate of ideas were frequent and encouraged. Further to that, protagonists exhibit an ability to come to the debate without ego and a willingness to leave a position previously held when the debates logical outcome cannot support their position. I have in the past witnessed what I call the ‘developers mother Teresa effect‘ where a developer will hold on to their position when all else seems lost, purely out of a need to save it’s soul.
What was fantastic about today’s debate was that it started out around a single issue and flowed into a much broader discussion that lead to a great number of issues and solutions that had not yet been considered much less understood. So what started as a debate over a single topic ended with an array of solutions to a number of issues that were previously hidden - a very positive outcome all in all. Along the way we argued (debated) our viewpoints strongly but never was their hint of dying for a cause borne out of it’s ownership. In some small way it reminded me of TDD, in the sense that as a group we were able navigate an outcome from testing our opinions and ideas, in the same vein as one discovers the design of code through testing.
Recently our team has been engaged in developing a highly scalable batch processing system, which to be fair didn’t require much beyond a fairly simple User Interface with few screens. Given our choice of WPF as the technology to build the presentation layer, we decided to extend our curiosity in SketchFlow and put it to the test in a real live project.
So, off we set and created our prototype and when completed, sent it on to the stakeholders to cast their critical
eye upon it and provide feedback using the SketchFlow players tools for capturing feedback. I must admit that I wasn’t convinced that our users / stakeholders where going to be particularly enamoured by the experience but I am happy to say that I was wrong- so incredibly wrong. Whilst developing the prototype I found myself continually applying my own biases toward the tool and they were such that I was developing an opinion that SketchFlow’s feedback mechanism was a little too simple and perhaps even ‘clunky’ to provide them with an experience that they would consider productive or enjoyable. However, the feedback came through very swiftly and along with it an enormous endorsement of the process, tool and the whole experience.
These user / stakeholders are used to defining and or changing a proposed UI layout in well known visual design applications (unnamed) and feeding those design documents accompanied with text documents (for annotation) to the software team for consideration. These documents would bounce between parties until a finalised design had been settled upon.
This time, upon having been supplied feedback via SketchFlow, they are reporting a significant amount of saving in time dedicated to the process and they are attributing that time saving entirely to the ease of use and functionality of SketchFlow. Now it’s early days yet and I don’t want to get carried away until we get a few more iterations into the process, however I am feeling pretty excited when our users come back with such positive feedback in their experience of the whole development life cycle.
And there I was, ready to put the kybosh on the idea. I cant argue a case when the business stakeholders show you nothing but thumbs pointing in an upward direction.
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.
