Most people who have worked with me have heard me preach about the importance of transparency. There is an old-school tendency in IT to view software as some sort of ‘magic’. Those paying for the software prefer to look at it this way, because it means that they are not expected to understand it. Those developing the software don’t seem to mind because it means nobody is questioning what they do.
Unfortunately, this creates a big gap between the end-user’s understanding of their software and the actual implementation of their software. It’s like the old trick where you whisper something into another person’s ear and then have that process repeated amongst 10 other people. When the last person is asked to repeat what they’ve heard, it is always different than what was put forth in the beginning. This is what happens when customers ask us for something and we try and build it on our own, without any checkpoints. The software becomes less aligned with what was requested, but further more, the end-user is distanced from its implementation.
Agile thinkers approach this in a much more effective and efficient way. They bring end-users as close to the implementation as possible so that the gap between their business and the technology driving their business is reduced significantly. They make transparency the focus in every process. I mentioned in my post about the Agile 2007 conference that there are a number of ways to facilitate transparency (I called them visibility facilitators) on any project, including open work-spaces, project collaboration / management / dashboard tools, and regular feedback. Conducting retrospectives and collecting metrics and velocities are also valuable tools for facilitating transparency. The obvious facilitator, not mentioned in that list, is on-site development with dedicated end-users staffed specifically for the project.
It’s not enough to have transparency in the process though. We need to take it one step further and develop transparent software. This has always been a battle for me, because I am so passionate about software usability, and I understand that rich UIs need to be able to hide system complexities in order to enhance the end-user experience. What I don’t like about that type of thinking is that it often results in systems with unnecessary complexities. While every problem has inherent complexities, we have to do our best as software developers to avoid introducing additional, unnecessary complexities. Often, these unnecessary complexities are masked by very non-transparent UIs. I live by the words ‘No Magic’, because I believe that a good UI should be communicating with the end-user, the same way that it will be communicating with the system. For example, if I click a button that says ‘Calculate Reconciliation’, I would expect that the interface is going to tell the system to ‘Calculate Reconciliation’, NOT ‘Calculate Reconciliation AND Send Various Emails AND Update Invoices, AND …’. While the extra steps taken may be useful, I didn’t really ask for it, so I start to feel like there is a bunch of magic going on behind the scenes that I don’t know about. I hate magic! My thoughts are that interface developers should start with the most transparent interface possible. Try to align the language on the screen as much as possible with the language used in the system (and visa versa). Try to expose function points or system intentions with obvious controls. Only when everything is fully functional should you start making UI tweaks that depart from back-end design. Lastly, I think it is important to push changes in understanding vertically through every layer of the system as often as possible. If this week this business are calling the Calculate Reconciliation function Reconcile Books, make that transparent and push that language through every layer of the system. Likewise, if a data relationship changes from 1-1 to 1-many in the back-end, make that transparent and push that relationship through every layer of the system so that if possible, it is obvious even in the interface.
No related posts.
Related posts brought to you by Yet Another Related Posts Plugin.
2 Responses to “No Magic!!! – Transparency is Key”
Who's linking?
"[...] wrote recently about transparency being key in software development. I think that another way to move in this [...] "
"[...] spoke before about the importance of transparency and I don’t think working in silos is conducive to successfully delivering ..."