EN
KIS is undertaking a company-wide initiative to drive quality and consistency across all of our projects. To achieve this, we’re making design thinking central to our solution approach. By design thinking, we don’t mean the thought framework, but the process of thinking about and designing our systems will work before we even begin to write the code.
Producing code from thought is one of the greatest joys a software engineer can experience - but only if the code actually works. It might be hard to grasp, but we can code more efficiently if we think more and spend less time on the keyboard.
We recently had an intriguing Lunch and Learn in which Jacob Beck told us how building his own bedframe related to this topic. The discussion we had at that event was so interesting we decided to share the key insights we had in this article.
It all started with a personal project: Jacob wanted a bedframe. But not just any bedframe. He wanted a floating bedframe.
A quick search on the internet revealed just how expensive floating bedframes can get, so he decided to build one himself.
At the time, lumber prices in the US were skyrocketing. To minimize costs, Jacob couldn’t afford to make mistakes. His solution was to invest more time in designing the frame.
This involved many measurements and calculations of the center of mass for the bed, its dimensions, and exactly how many pieces of lumber and screws he would need.
He and a friend spent two weeks on the design, swapping ideas, sharing tools, and calculating the total costs of the material. Once they bought what they needed, it only took them one afternoon of work to put together the floating bedframe Jacob had envisioned.
Jacob was happy with his new bed setup and his buddy was happy that his time was well spent.
Although we make software and not bedframes at KIS, Jacob’s story relates to the work we do. Below are some lessons learned over the years at KIS that connect to this analogy, and some that even go beyond that.
Designing the solution before starting implementation is an investment of time and effort. It might seem counterproductive, but spending more time designing a project reduces execution time.
Thinking and writing down how the solution will work helps to organize thoughts and offers a great communication tool to get other people’s input.
This process can reveal major logical holes that would otherwise cause big refactors when uncovered later in the development, which would exponentially increase the delivery time. Changing a design document is much easier than refactoring code.
Having a solid plan to implement a feature means fewer issues and less re-working throughout the process resulting in a project that makes us proud and our clients happy.
Designing the solution helps us estimate the number of resources needed to complete the project with little to no “leftovers”, whether those are planks and screws for a bedframe or people working on a system migration. And, since “time is money”, shorter execution time also cuts down on expense.
This is a fundamental value for KIS. We love to code, but our primary goal is to solve our clients’ problems and deliver value to them.
Our clients trust us with their money. We are committed to making the best use of it by solving their needs without wasting resources and time.
Design is a communication tool. Putting ideas on paper helps communicate the vision of the project to the parties involved.
In the bedframe analogy, Jacob’s friend brought knowledge and resources that helped make the project successful. He offered Jacob his tools and suggested buying lumber from a specific vendor that would give them some cuts for free, saving money and making their work easier overall.
This is how we at KIS think every software project should be: a 2-way partnership between the tech team and the client. And design plays a major role in this relationship.
It helps us communicate to our clients what we intend to implement and how it should work. In return, we get their input, further helping us understand their needs, making sure it will be useful.
It also helps us talk about what needs to be done with our own team and give clear tasks to our developers, QAs and other people involved in the project.
Regardless of the technical background of the people involved, good designs help explain complex systems in simple, easy-to-understand terms.
The bedframe design wasn’t perfect. Jacob and his buddy still faced some issues when assembling the bedframe but only by a centimeter here and there—never a whole meter.
It’s important to remember that a good design will never be bulletproof. But it will help to ensure that any unforeseen issues will be easy to manage instead of putting the whole project at risk.
The bedframe story is a fun way to think about the work of a software engineer, but there are some core aspects of the job that don’t relate to the analogy.
Let’s look at some other lessons learned that illustrate these aspects.
We talked about how design communicates the vision of the project. However, this plays an even more important role when talking about software.
If, one day, a friend of yours said to you “I’m building a bedframe”, you would immediately have a general idea of what they were trying to do. You might not envision a floating bedframe, but you would get the main ideas: It must support a regular mattress (single, queen, or king), it must be a couple of inches above the ground, etc.
You could do that because you have seen dozens of bedframes in your life. However, if I said, “We are building a consumer matching algorithm”, what comes to your mind? Have you seen a consumer matching algorithm before?
Even if you have worked with one before, can you imagine all the methods it needs to have? Do you see the code with the curly braces? It doesn’t work like that. Software is abstract.
I’m sure you are a very smart person and that you may have an idea of how this algorithm should work, but it would probably be very different from what other people would think.
It’s harder to come to a consensus on how abstract software needs to work. It requires a lot more communication. Having something in common to “point at and talk about” helps to avoid misunderstandings. The design is that something in common.
Think about building a bridge. Mixing and pouring concrete in the ground is “easy work”, but doing so in a way that it forms a solid bridge is a whole different challenge. Every world class engineering project requires a blueprint that is created and reviewed by several engineers.
Writing code is fun! But, in the same way, the design and architecture of a big system is the real challenge.
A recurring pattern we see among software engineers in the industry is their tendency to jump straight to coding. Why is that? Why not spend more time designing our solutions like in other engineering fields?
One could argue that the stakes that most commercial software projects face are not as high as the bridge example. If a bridge falls it can injure people. That doesn’t happen if a global consumer database stops working. Additionally, fixing issues is cheaper and easier. For example, a critical bug can be fixed in a system in a matter of hours without having to recall thousands of products.
Nevertheless, this is not an excuse to not think about and design these systems in our field. Here at KIS we build world-class software. Some of our projects are used by millions of people in more than 50 countries. If these systems malfunction, it could cost our clients millions of dollars!
We must have the same commitment to “getting it right” as engineers from other fields.
The topic from the section above is true not only for people with the “engineer” title.
The job of an engineer is to solve problems. At KIS we believe that everyone involved in a software project is responsible for solving the client’s problems and should have this engineer mindset. Each person should put in the time and effort to make good designs and plans for their tasks before jumping into the “building” part regardless of their title.
This mindset goes beyond the design process. Some common products like keyboard keys are tested to a level of 100 million clicks each to make sure they will work reliably.
Software might not be as tangible as a keyboard, but most applications we develop need to run flawlessly all day, every day. So why not apply the same level of testing to them?
This discussion brought up some great points around the philosophy of design. No matter how smart you are, when working on a project, having an idea about what needs to be done and how to do it is only half the battle. Don’t skip the “write it down” part.
Documentation and design are not a waste of time. It doesn’t add time to the process. It is a part of the process of delivering world-class projects. It adds trust that the project was well thought out and is reliable.
I don’t know about you, but if I found out that a bridge in my city was built in an afternoon by a couple of people without much thought behind it, I would not want to cross it. Don’t give that same impression to the people using your software. Be an engineer, make a design.
.png)
