If you want to get some furniture custom-made for you, you just need to walk into a woodshop with a drawing of exactly what you want and when you go back in a month you can take it home. That’s it.
But when it comes to building software, things are not as simple. So, why do most people get the wrong impression?
Let’s first understand that names matter and so do definitions. They trigger judgments and define expectations. And there is a dangerous misconception around software, that can be summed up by the use of the term “Software FACTORY”.
The term dates back to the earliest years of the computer era, when experts were trying to approach software development with the same industrial logic that they used for hardware manufacturing. This would be by dividing the workload into repetitive tasks, resembling Ford’s automotive mass-production assembly line… you know the drill. In short, workers were taught how to perform one task and then they would repeat it endlessly without ever questioning the process behind it.
However, Software Engineers kept finding it difficult to produce useful and inexpensive software through an industrial approach.
Sure, many of the practices used during the development phase can and will be automated, for example, picking the right frameworks and tools that help build and ship faster. However, there are many parts within the development process that are still not possible to be automated. You think a system through when you design it. You think the system through a second time when you code it. You go through it once again when you test it. And you repeat this cycle again for every change you introduce into the product. All of these steps require intellectual input. All of these steps require technical expertise, creativity, and strategic decision making. None of them is the result of a worker on automatic mode over an assembly line.
Even setting programming aside, building software is complex. I’m talking about the kind of problems that software usually tries to solve. Pinpointing the root cause of the user’s pain is not as easy as it seems in an environment where many variables are constantly changing. The software world is extremely competitive. Software users are picky, impatient and most times don’t know what they need. What’s more, what they need today may change tomorrow as the context around them varies. This is what makes following a plan not as important as being open to change.
This is one of the many reasons we swear by building products in an Agile way. We strive to innovate and maximize the value we deliver to the user by placing careful attention on their evolving needs and reacting quickly. We build new products every day and we often even build new approaches to the same products. For more similar than it might seem, we never do the exact same thing twice.
For the past 6 years, our area of expertise has been solving problems through Software, particularly through web and mobile applications. We take pride in our teams’ decision-making skills that provide our customers with a quick time to market while maintaining high-quality standards. That’s what we do best.
For us, software development is more about co-creating with our clients than building something for them.
Therefore, since the moment we take on a new project, the team’s priority becomes solving the riddle the client brings to the table. We scratch up to the root cause of the problem. We evaluate alternatives. We brainstorm ideas. We bust our heads off designing the best user experience and we finally bring the solution to life. All in all, to then repeat the cycle with a new insight. Does this sound anything like mass-production?
We are closer to the idea of crafting and experimenting than we are to mass-producing. We like to think of ourselves as artists with a practical approach. We don’t just build awesome things for the sake of it. What’s the point of building a super cool app if nobody wants to use it? If it doesn’t make anybody’s life easier? We are part craftsmen and part doctors. We come up with beautiful ways to cure pain.
That’s why we define ourselves as a Software Development Boutique. We provide a tailored and expert assessment that implies flexibility and full transparency with the customers we collaborate with. This includes discerning between what the customer thinks he needs versus what he really needs and being open about it.
In short, our teams are trained to solve problems, not to assemble products. Sure, the manufacturing part eventually happens, but we do way more than just that, and our value resides somewhere else.
So no, we are not a Software factory.