KIS is undertaking a company-wide initiative to promote quality and consistency across all our projects. To achieve this, we’re making design thinking central to how we approach solutions. By design thinking, we don’t mean the thought framework; we mean thinking about how our systems will work before we even begin to write the code.
Turning an idea into code is one of the greatest joys a software engineer can experience — but only if the code actually works. It might be hard to grasp at first, but we code more efficiently if we spend more time thinking and less time at the keyboard.
Thisidea, that thinking through things beforehand will save time in the long run,can be applied to anything. Our software engineer Jacob Beck recently told usduring a Lunch and Learn how he used design thinking to build his own bed frame. Our discussion during the event was so valuable we decided to share our insights and takeaways in this article.
It all started with a personal project: Jacob wanted a bed frame, specifically a floating bed frame. A quick internet search revealed how expensive floating bed frames can get, so Jacob 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 the design process. This involved taking many measurements and calculating the center of mass of the bed, the frame’s eventual dimensions, and the exact number of pieces of wood and screws needed.
Jacob and a friend spent two weeks figuring out the design, swapping ideas, sharing tools, and calculating the total costs of the material. Once they had bought what they needed, it only took them one afternoon to put build the floating bed frame that Jacob had envisioned.
In the end, 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 bed frames at KIS, Jacob’s story is a great analogy for the work we do. Below are some lessons we’ve learned over the years when it comes to design thinking.
Designing the solution before starting implementation requires time and effort, but it’s worth it. While it might seem counterproductive, spending more time designing a project actually reduces the execution time.
Thinking about the solution and writing your ideas down is a great way to organize your thoughts, and you have the opportunity to get other people’s input at this stage. Careful planning ahead of time can also reveal major holes in logic that might otherwise later cause big refactors and significantly increase the delivery time. Remember: changing a design document is much easier than refactoring code.
A solid plan to implement a feature leads to fewer issues and less reworking down the line, resulting in a project that makes you proud and your clients happy.
Designing the solution helps you estimate how many resources the project needs with little to no “leftovers,” whether those are planks and screws for a bed frame or people working on a system migration. Since “time is money,” a shorter execution time also cuts down on expenses.
This is a fundamental value at KIS. Our clients trust us with their money. We are committed to making the best use of it by solving problems and delivering value without wasting resources and time.
Design is a communication tool. Putting ideas on paper helps convey your vision of the project to other people.
In the bedframe analogy, Jacob’s friend looked at the design and brought his own knowledge and resources, which helped the project succeed. He offered Jacob his tools and suggested buying lumber from a specific vendor who would cut some of the wood for free, saving money and making their work easier overall.
This is how we at KIS think every software project should be: a two-way partnership between the tech team and the client. Design plays a major role in this relationship by helping us communicate our plan and how it should work. In return, we get their input, further helping us understand their needs and ensure our product will be useful. This also helps us give clear tasks to our developers, QAs, and other people involved in the project by determining exactly what our team needs to do.
Regardless of the technical background of the people involved, good designs help explain complex systems in simple, easy-to-understand terms.
The bed frame design wasn’t perfect. Jacob and his buddy still faced some issues during assembly: some of the measurements were off but only by a centimeter here and there — never by a whole meter.
It’s important to remember that a good design will never be foolproof, but it will help mitigate unforeseen issues that might otherwise put the whole project at risk.
The bed frame story is a fun way to think about software engineering work, but there are some core aspects of the job that don’t fit into the analogy.
Let’s look at some other lessons about design that we’ve learned over the years.
Design helps others envision the final product and the steps to get there, especially with software.
If, one day, a friend of yours said they’re building a bed frame, you would immediately have a general idea of what they were trying to do. You could even adjust your mental image after learning it’s a floating bed frame and easily understand the main requirements: support a standard mattress (twin, queen, or king), sit a couple of inches above the ground, etc. You can do that because you have points of reference; you’ve seen dozens of bed frames in your life, even if none of them were floating bed frames.
However, if that same friend said they’re building a consumer matching algorithm, what comes to mind? Have you seen a consumer matching algorithm before? Even if you have, can you imagine all the features it needs to have? Do you see the code with the curly braces? It doesn’t work like that. Software is abstract.
Even if you have a clear idea of how this algorithm should work, it would probably be very different from what other people would come up with. Coming to a consensus on how abstract software needs to work is difficult and requires a lot of communication. Having something in common to “point at and talk about” helps to avoid misunderstandings, and a design acts as that reference point.
Think about building a bridge. Mixing and pouring concrete in the ground is straightforward enough but doing so in a way that forms a solid bridge is a whole different challenge and requires careful planning. Before beginning construction on any engineering project, several engineers design a blueprint, and then even more engineers review it.
Just like other engineers, the design and architecture of a big system is the real challenge, but many software engineers in the industry tend to jump straight to coding. Why is that? Why not spend more time designing our solutions like in other engineering fields?
It’s arguable that, compared to other engineering fields, most commercial software projects face lower stakes and are cheaper and easier to fix if something does go wrong. If a bridge falls, it can injure people; that doesn’t happen if a global consumer database stops working. Even critical bugs can be fixed in a matter of hours without having to recall thousands of products. This might suggest that designs are less necessary when it comes to software, but this isn’t true. Software still directly impacts people, and there is no excuse to be careless.
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 have the same commitment to “getting it right” as engineers from other fields.
You don’t have to be an engineer to benefit from thinking and acting like an engineer.
Engineers solve problems. Anyone, regardless of their title, can solve problems by putting in time and effort, making good designs, and planning for their tasks before jumping into the building stage. At KIS, we believe that everyone involved in a software project is responsible for solving the client’s problems and should have an engineer’s mindset.
This mindset also goes beyond the design process. Engineers thoroughly test products to make sure they will work reliably. For example, each key on a keyboard might be tested up to 100 million times. Software might not be as tangible as a keyboard, but most applications we develop need to run flawlessly all day, every day. So, we apply the same level of testing as any other field of engineering.
When working on a project, whether that’s a bed frame or apiece of software or a bridge, thinking about what needs to be done and how todo it is only half the battle. No matter how smart or confident you are, alwayswrite down your ideas so you can reference or share them later.
Documentation and design are not a waste of time. They arenecessary parts of the process for delivering world-class projects that buildtrust with the client by demonstrating that the project was well thought outand will work reliably. They may also even save time in the long run by preventingavoidable errors.
People don’t want to use a bridge that by a couple of peoplewithout much thought behind it. Don’t give that same impression to the peopleusing your software. Be an engineer: make a design.
.png)
