Building software is like building a LEGO house

One of the problems of the software development industry, is non-software people making decisions about software builds. Many of these people believe that building software is like building houses, which it is not. People see the software business, approach it like building a house, specifying upfront and asking when it is finished. Assigning project managers as general contractors and hiring cheap labor to execute the build. I can hear some managers who are reading this think: Wow! Can we do that? That is the answer! No, it is not, we tried it for more than a decade and it failed spectacularly. They even came up with a name for it: “out-sourcing”.

But even though we move from Big Design Up Front (BDUF) to Agile the analogy of building houses is hard to get rid of. Yes, we know we do Agile with sprints, no deadlines just sprint goals and a backlog with user stories and a road-map with epics. But we are still building a house. Well.. no.. we are actually not building a house. The whole house analogy is wrong. We are building a LEGO house. Yes, something like this:


Was it a coincidence that Paul Hammant used a LEGO picture in his post about software architecture? I think not. Here are some of the points that show why building LEGO house is a good analogy for building product software:

  • Innovation: Best builds come from experimenting constantly and thinking out-of-the-box.
  • Flexible: LEGO house foundations can be replaced carefully. Anything can be replaced any time.
  • Looks: Building a pretty LEGO house is very hard and requires special skills.
  • Agility: There is no such thing as a “done” LEGO house. It is alive and constantly changing.
  • Requirements: You don’t plan building a LEGO house. You know what you want when it evolves.
  • Specs: LEGO is enjoyed best by building whatever comes to mind, not by following specs.
  • Compatibility: Everything connects to everything, with hardly any effort.
  • Freedom: LEGO can be build without having to comply with all kinds of regulation.
  • Creative joy: Creating software is as much fun as creating with LEGO.
  • Value: People pay for the promise of easy integration and high flexibility.
  • Validation: A real-life test by the target audience tells you things you could not imagine.
  • Mindset: Grown-ups do not understand LEGO, like business does not understand software development.
  • Out-sourcing: If somebody else builds your LEGO house, you will get something you don’t like.
  • Standards: Build with non-standard blocks and you’ll get stuck quickly.

Can you think of other things in which the analogy is right? Use the comments! Don’t comment saying that I do not take software development serious. I believe that software development is a serious business, but it is also seriously fun. To put it stronger: If it does not remind you of playing with LEGO when you were still a kid, you are doing it wrong.


Functional Design: Why making requirements matters

Within our daily life, changes come along, as do the decisions on how we deal with them. These changes appear in your personal life and also in your professional life. And this is no different at LeaseWeb. Technology is changing and so are the wishes of our customers (and customers can come from within LeaseWeb and from the outside). And sometimes the changes that are requested are big and sometimes the changes are smaller.

But at the start of every change there’s always the same question: “Why do you want this change?” This can be to sell more products, to increase customer satisfaction, to keep ahead with the competition, to lower the manual actions so less hours are spend and more money can be earned and so on.

When the reason of the change is clear, it must be made clear what needs to be changed and what the change should look like. Say, for example, that you are a woodwork shop and a customer tells us he wants a new bed. As a woodworker, how do I know how this bed must look like? As I start building the bed with only this information, there is a big chance I will build something like this:


Image source: IKEA, FJELLSE Bedframe

How do I know, before I start to build it, the customer is thinking about this:


Image source: Rocking Bed – Private Cloud 

Obviously, LeaseWeb does not make beds, but we do run into this kind of problem, when we try to build software.

So all this comes down to the problem of making requirements. By asking the customer what he wants in detail, the chance is bigger that the development of the product will possess the correct critical properties and not possess the properties that were not requested. Expectations will be met more precisely and any rebuilding of the product will be less. So the costs will be lower (at the end) and time will be saved (by not rebuilding and remodeling the product). And most importantly, the customer will be more satisfied with the result. So, the most important activity in starting to build a (new or changed) product is to properly gather the requirements for the product.

There are four core activities within the requirements engineering process:

  • Elicitation: defining and refining the needs and wishes from different stakeholders in a most detailed way
  • Documentation: the elicited requirements are described adequately
  • Validation and negotiation: requirements are checked if they meet the predefined quality criteria; requirements that are inconsistent, are negotiated between stakeholders
  • Management: measures that are necessary to structure requirements, to prepare them so they can be used by different roles, to maintain consistency after changes, and to ensure their implementation

These are also well described on the requirementskenniscentrum website (in Dutch) and in the post called “requirements engineering explained” by Mike Polga.

So, the next time, when someone from functional design is at your desk and you’re thinking: “Why all these questions? I only want a bed”. Then realize that these questions are asked to understand the requirements: what kind of bed you want, what you’re going to use it for, how long you want to use it, for what purpose and for which costs? By telling him (or her) everything you’re thinking about (and more), you increase the chance that you get a product that meets your expectations, within time and within your budget.