Wednesday, December 16, 2015

The Importance of Understanding Expectations

A recent acquisition of a set of new chairs shed some light on how a solution can meet requirements while at the same time fall short of expectations. This caused that sudden realization to solidify in my gray matter. The upshot is that meeting requirements is a science while meeting expectations is an art. A friend, mentor and colleague has repeated so many times that software development is as much art as it is science - the majority of the chorus being sung in regards to choices of patterns and styles when coding. I want to come back to that though, but for now let me share a bit of the story of the chairs.


We were in the process of getting a new office space and one thing that came into play was the choice of new chairs for a communal/meeting/lounging area. The idea was that the chairs could be circled up to facilitate discussions. The first option had feet with pads, a bucket design, and a little desk top attached. Well, it would have been nice to have wheels and if the desk was removable so that it wouldn't be in the way if not needed. This feedback was given and the next sample chair that arrived with casters and a removable tray.


A few days later a sample arrived that fit those requirements. At first sight was a bulky eyesore of a white leather chair, with dirty handprints all over the back to boot. Then I rolled it around and the casters felt as if they would fall off. The removable tray was on the left - only on the left. It was nearly useless as it was genuinely too far away for comfort given the size of the chair and it was generally too small to support a laptop comfortably.


What is the lesson here? You get what you ask for! But seriously, think about how those requirements created solutioning constraints. What we needed was a modular place to gather comfortably and talk face-to-face for short durations. We needed the space to be able to double as a viewing space for presenting ideas, plans, apps, whatever. This is the art - understand the users needs, environment, and their expectations. Once you understand the users in this way, then you should have a better understanding of what solution to provide.


Now lets return to the code for a minute. Choosing design and style of architecture and code is an art. In order to deliver to the needs and the expectations, we must first understand the users of the code and deployment. Sometimes, you are the user and sometimes other developers. Ops teams could be users. What goals will users have in the future? There will be a need to change the code - its code of course so it is always changeable. The code will have to be changed in ways so that unexpected things do not happen. Other developers will want to understand the code, and without a whole lot of pain. You and others may want to be able to write unit tests against the code, or other forms of automated tests. Sure you could obfuscate everything and keep the code as compact as possible, keep it super-efficient, keep it obscure so that only the mightiest of developers can understand it. var a=g();a++;if((b===x&&y!==l)||(z|1)&&((((((m())+5/c)&3)|(l-5)))){return g===h?(6*f)>=9?'v'::''.....
but why would you put future you through that? It's like looking at a Jackson Pollack piece, except that someone will have to change it someday. Imagine what kind of mess you'd end up with if over time several other painters of varying skill level changed one of those paintings...it would probably end up a muddy looking mess before you know it! Instead its a nice clean mess.


Sometimes we inherit a Pollack. And sometimes we are asked to change a Pollack. Oh where to begin! In this way, the art of software can be lost in the science. The art of software is more like a mural on an endless wall...you can add on without destroying the original, especially if the original lends itself to extension and to change. Picture a mural on a wall that begins to the left and continues endlessly to the right. If the first part has lines that lead the eye to the right, we have something to build on. If it has white-space we can add to it by filling in the space. As our mural is continued over time to grow to the right, we may decide to change a part somewhere to the left of the current one. Themes can be continued, but maybe some offensive part will be changed or something later causes an earlier work to be inadequate and that part would need to be revitalized lest it bring the whole down.


When applied to software, we must think of the art of it as well as the science and leave our designs and styles open to change and before that to be understood.

No comments:

Post a Comment