And now, if I turn the image 90 degress clockwise, what do you see?
Most people will see a frog on the first drawing and will still see the same frog in the second drawing, but some people will be able to see a horse in the second drawing, and a few people will recognize both the frog and the horse already when looking at the first drawing.
Which one is right? Why some people see first a frog and why others see first a horse?
Our perception of the world that surrounds us can change as quickly as we learn and absorb new knowledge and experience. And that it’s totally ok!
The way you see or understand a situation presented to you is based on the frame of reference you have at that moment in your brain. It doesn’t necessarily represent reality. What you get is an interpretation of the reality based on your beliefs and experience, your mindset.
Another person with a different background and life experience might interpret the same situation at hand differently and build a different reality. That’s the reason why is so important to be super careful about what you think and really reflect on how these thoughts and interpretations are influencing your actions and behaviors.
The problem is when you don’t recognize this dynamic and believe that the map you have, which most of the times you don’t even know that exists, is the only one that matters and the truth. That’s when people start to become pushy, dictatorial, etc.
When you don’t accept that there are other maps and consequently other interpretations of the same reality, you’ll not advance yourself as a person. You’ll be a prisoner of limited interpretations. Yes, some maps are better than others. They have a better representation of the terrain and the key for me is that one can develop a mechanism for recognizing such better maps and improving her own maps.
Acknowledging this natural law and being open to evolving your maps, your frame of reference, is what will really make a difference in terms of personal and professional evolution over time.
I watched Jez Humble’s talk at Agile 2017 and among many insights, one particular thing caught my attention.
He based his continuous delivery philosophy on the UNIX design philosophy.
I’m a big fan of UNIX and everything it powers nowadays. However, this connection between UNIX’s design philosophy and Jez’s Continuous Delivery approach was very intriguing for me. You can watch the talk here. Skip to minute 4:30 to watch the UNIX part of it.
I’ve read the referenced paper on his slide and surprisingly enough I discovered it very up to date as for what we’re having nowadays as trends in IT. You can read the paper UNIX Time-Sharing System: Forward. (McIlroy, M.D.; Pinson, E.N.; Tague, B.A.) here.
A quick Look at UNIX system design style and some parallels I made
Make each program do one thing well. To do a new job, build an afresh rather than complicate old programs by adding new features.
This principle could perfectly be a description of the overall idea behind Microservices. Also, I can related two of the SOLID principles with it: Single Responsibility and Open Closed.
Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
This sound a lot like an API and its relatives like Design by contract, APIs first.
Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.
Impossible not to remember of a Prototype reading the principle above. Also, Iterations, Sprints, Fast feedback loops, Spikes.
Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.
Workflow automation and supporting tools for software development such as IDEs, Analysers, CI/CD, Platforms, high-level languages, etc.
An insight I had while reading the paper was realizing how pretentious or arrogant some inventors/creators are when they believe that they truly invented something revolutionary or even when we master certain skills that we ignorantly think is new but are nothing but old very good software development most of the times with a cool name or wrapped up on a framework.
This kind of material should be more available to every developer. I’m sometimes concerned with people that take courses on HTML, CSS and JS and assume they’re good developers right after finishing the course. They have so much to learn as I do even after all these years of software development. Also, all the agile movement should acknowledge that in the great majority of the cases they just made smart things invented in the past more accessible or sellable.
So in general, I started to believe that part of the truth on how to build quality and sustainable software resides in the past and it’s just waiting for us to discover it. Perhaps this will reduce a lot of the hype we’ve seen lately and we’ll be able to focus more on what we really like, well at least the great majority of us: Software Development.
Recently I’ve read some statements that keep coming to my mind at least once a week maybe more.
1 – Make it work, Make it write, Make it fast
I’m a big fond of the concept of “Right first time” but lately I’ve seen so many time being wasted trying to figure out what would be the “Right” thing to do. Many unnecessary conflicts, concerns, non-validated assumptions, etc. This made me think more often about extreme interpretations or even shallow interpretations of such concepts that when not fully understood or discussed could lead to inefficiencies everywhere.
When I have such thoughts I remember of this concept that says: Make it work, make it right, make it fast! I don’t remember exactly when I’ve heard it for the first time but I’m sure, unless my brain is tricking me, that I’ve heard it during some research about game development (which is something I kept coming back to from time-to-time) and it was related to Blizzard, one of the big players in the game industry.
Later, after some additional research, I discovered that this term is actually attributed to Kent Back and it was part of the UnixWay for a long time.
Anyway, the whole idea is that when solving a problem in an iterative way you should consider to first make something that works, even if it’s not the right perfect solution. Ship it and learn from the feedback you’ll get in order to go to the second step, make it right. After rounds of improvement based on feedback then you’ll have to at some point make it fast. That will be the last step. That’s at least the intepretation that makes more sense to me.
I just feel that many times this simple and pragmatic approach will bring much more value than trying to use a sophisticated one just because everybody else is doing. But that’s just a feeling. I don’t have any data or experiment that can prove that, so maybe in the future, I can experiment with this approach and see what happens.
2 – The tiniest thing shipped is better than the best thing planned
This was something I’ve read on a blog post published by Amy Hoy on how to overcome procrastination.
This statement resonates with me because it sounds very responsive and lean, which is something I like. Also, it has a connection with the first idea as well, I believe. Living in the world of ideas and planning is super comfortable and can make you feel in control of things, but the truth is that the time will pass and all you’ll get is pure fantasy.
I spend so many hours planning stuff. I do that every day as part of my job, and I do that every day as part of my personal development. I try to make it as lean and efficient as possible. However, my feeling is that last year I tried to have the “best thing” planned instead of just shipping stuff to the real world, even if it was something small. Although I shipped, for instance, an email plugin for JIRA named Issue Events Mailer, a crap todo list style bookmark app, and another small attempts into the real world, I just have the feeling I could have done more if I had this “mantra” in my mind every time I questioned myself if what I was doing was of any value.
3 – A good plan is worth its weight in (future) gold
Also, I learned during these years of professional contact with lean and agile methodologies how bad too much planning can be. I’m not saying that plans should not exist, but we have to understand how much effort we should put on them before actually putting it in practice. At some point more planning is pure waste of time and energy that could be used for other valuable actions or tasks.
In the past things were so expensive that a well-thought plan was mandatory. The cost of repairing an error was too big. This is still true for some industries or fields of knowledge nowadays but for the great majority of software-based projects, for instance, I see these practice of thorough planning not optimal. Today is cheaper to quickly iterate, ship something, learn from it and use the feedback as input for a new iteration. That’s the base of lean and agile product and software development. Very quick cycles of plan-do-check-act. This makes me think that often just having alignment and shared understanding around the problem we’re trying to solve will be enough to a team or a person to start developing something and especially delivering something that can be used and criticized – in a constructive way – early and often.
Yes, I might have generalized things a little bit. Reality might be not as sweet as I’m painting above, but in general I believe that this principle and the previous ones should be taken more into consideration when we do or plan our plans.