It sure seems easy to make a table. Anyone can do it, right? Get 1 large flat rectangular piece of wood, 4 equally tall wooden poles, 4 nails and a hammer. Nail the 4 poles to each corner of the flat rectangular bit, and you have a table. Ta daaa!

Now ask a carpenter to craft you a table. First they will spend time discussing the purpose and function of the table - indoor or outdoor, kitchen or dining room, for show or heavy use, what load does it need to bear. Then they will determine the materials to use - hard vs soft woods, laminate, plywood or railway sleepers. Then they will look at the aesthetics of the table - beveled edges, foot design, center or corner mounted legs. And when they finally get down to crafting the table, they spend a lot of time to mitre, mortise and dovetail all joints, install bracing points, use quality glues, dowels and screws, test its levelness, sand it flat, stain it, seal it, polish it and produce a table they are proud of. Seems a whole bunch more work, doesn’t it? It just a table, no?

But there are differences between the two approaches, did you see any?

The table with four nails looks shoddy, it’s wobbly because the legs are not squared, has a warped top, will not last a week before a leg spins itself off and cannot be trusted to bear the weight of single salt shaker. The carpenter’s table looks better, works better, both feels and is solid, does not wobble, has squared legs, is flat, does not give you splinters, lasts way way longer, and can be relied upon to keep a full dinner and a few partygoers off the floor. Which would you rather have?

When it comes to software, most people assume the workload is much like the first table creation approach. Just create a database, fill it with some data, draw a few screens and you are done, you have a software product. I have absolutely no idea where this thinking comes from. Maybe it’s the Excel mindset - “I can do it in excel, so programming it should be easy”. What?

Crafting software is hard. And it is a lot of work. Very much like the way a carpenter approaches the table. As designers and programmers, we need to understand the business, use cases and function of the product. We need to discuss and understand who will use it, what kind of things should it do, how it integrates with other software, where will it be used, how much data, etc, etc, etc. We then spend massive amounts of time crafting the architecture, to make sure the software can handle the user and data load, can grow and scale, and can handle the volume needed (like load bearing on the table). We then spend even more time writing quality, readable and maintainable code, testing each and every component to make sure it works correctly and quickly, fixing bugs and bottlenecks (using the right materials and joints in the table model). We spend even more time assembling the components together, making sure each interface fits perfectly, making sure errors are handled, making sure that the UI is functional, simple and aesthetically pleasing (glue, screw, joint, sand, stain and polish the table). And finally, we hand it over, a complete product that can be relied on to do the job, a product that is fit for purpose, a product we and you can be proud of.

I trust that carpenters don’t have to face the same level of madness that we programmers do. Maybe their customers also complain that the table is taking too long to build, or costing too much, without understanding what is involved. Maybe their customers are also reticent in telling them what the table is for, or how they want it to look, yet complain loudly when it looks different to expectations that were never expressed. Maybe their customers are also looking them in the eye and telling them that the table should just take them a few pieces of wood and a few hours to make, that carpenters have been making tables for thousands of years so this table cannot be all that different. Maybe their customers are saying that it’s easy, and therefore should be done quicker, cheaper and, I guess, magically.

Our customers do exactly that. Almost every time. Without fail, requests I get for new features start with “It should only take you a few hours to ….”, or the “Why don’t you just do … this way because it’s easier”, or “Just make a quick change to …”. What?

Adding a feature to a software product does not a nail and a pole take. We need to understand the form and function of the new feature, create it, test it, document it, and ensure that the new feature does not break anything elsewhere in the system. If we don’t do that, the software will fail, be buggy, not work right and create more problems for our users. Lots of software out there is like that, and everyone who uses this cruddy software does not trust it nor enjoy using it. Just like the wobbly table.

If you want a new feature, feel free to request it but be prepared to discuss it in detail with us carpenters, er, software folks. We’ll craft the right solution for the application and make sure that it works right and keeps on working right. You came to us for quality, reliable software, just like you went to the carpenter for a quality table.

Just don’t tell us how easy or quickly we can do it unless you can do it yourself. If you truly believe it’s quick and easy to do, do it yourself. Go ahead, slap together a wonky table.

If you want a proper product, understand that crafting takes time and skill, there is a lot more to it that you can even imagine, that crafters are people with feelings too, and that a proper product is a joy forever, is worth both the effort and the wait, and should be something we can all be proud of.