At a family gathering recently we were discussing an artistic streak that exists in my immediate and extended family. When it comes to drawing or painting, that streak went by far too fast for much to imprint on me, but it certainly landed with one of my uncles and my late Mom. They’re both gifted artists, especially my Mom.
If not for raising 5 of us, she might have been a professional artist. Even so, she did produce numerous beautiful works and was even “commissioned” to draw or paint portraits of people a number of times.
Here is an example of her work from the late 1970s:
For Mom, drawing was a passion. It was a creative release for her that she loved. She was, however, a perfectionist. She would agonize over the smallest details, such as tiny leaves in a drawing of flowers that she felt weren’t quite right. She’d point out the “flaw” to me and I was simply incapable of seeing it - it looked incredible to me!
That perfectionism led to amazing works such as the one shown. It also had a downside.
Mom was terrible at playing Pictionary when it was her turn to draw!
One would think that a gifted artist would excel as quickly drawing a representation of the word or phrase she was given. However, she would use all of the time trying to draw the PERFECT representation, rather than one that’s good enough for the people on her team to guess the word/phrase! She just couldn’t stop being the “gifted artist” in order to achieve the goal of the game. Thankfully, my lack of artistic skills works to my advantage in that situation, but it’s probably the only time it does!
So what can we learn from this? Well, as with so much of software product delivery, context is everything!
Consider the two images of elephants above, which one would be better for the game Pictionary, where you have limited time to guess what the drawing represents? Which would be better for a contest where time isn’t restricted but the fidelity of the drawing compared to real life is most important?
When building any product we need to ask those questions. Is the quickly drawn “stick elephant” adequate for now or are there reasons why the more accurate and rich drawing is required? If we just need to receive feedback on an idea to ensure that it’s going in the right direction for the consumers of the work, the stick elephant is probably adequate. If, however, there are regulatory or safety issues at stake, we might need the accurate version right from the start.
In my experience over the years, though, I’ve seen time and time again teams and organizations immediately assume that they need the full version from the start. They require months to years to ship it and then receive feedback that it wasn’t an elephant that they needed but a giraffe instead!
Hell, I’ve even made that mistake myself! In the early 1990s I built an ad hoc report generator into a system that could do nearly everything for the user. It took me about 4 weeks to build & test and the reception from the 50 or so users was… crickets. No one every used it. Not a single person! Even I stopped using it for ad hoc requests because it wasn’t flexible enough. I didn’t remove it from the system, but I did replace the functionality with a skeleton report generating template application which I could quickly tailor to the needs of a specific report in a couple of hours. I would then send the resulting report application to the users for them to run themselves. I used that approach to create dozens of reports over a couple of years and the users loved it!
It took me a couple of days to write, test and extract the template after the first request. I wish I had taken that “stick elephant” approach first, rather than the month I spent writing something that no one ever used!
Feedback is at the core of the methods that live under the umbrella of Agile. While I had learned this mostly subconsciously before learning of agile methods, it wasn’t until I was introduced to Extreme Programming (XP) that it was truly made conscious. Agility is nigh on impossible without frequent feedback, regardless of whether you’re building yet another General Ledger system or at the bleeding edge of current technology such as the software for self-driving vehicles.
Regardless, the context in which you’re building something drives what represents “releasable” work. I wouldn’t want the “stick elephant” version of software driving my car for me. Similarly, I don’t need the “near photographic quality elephant” to see the menu of a local restaurant that I like.
When you’re planning some work, ask yourself which you need before starting!