Building Technology for the non-developer

Here we try to understand the complexity and level-of-effort in building software, and how it relates to other technology. Software is generally a 'mystery box' to most people, so using analogies to houses, cars or boats may make it easier to understand what's involved.

Building any technology can happen in the small or in the large and there are various forms in between those 2 points. Whether it is a house, car, boat or software; there are varying forms of each 'technology' and to actually complete building each form requires different skills.

Developing something to completion requires managing complexity. Very small examples may not have a lot of complexity. They are difficult to do well; but in the context of the larger picture they are the easiest form.

What

Developing any technology has varying levels of complexity, but generally follows a pattern depending on what form it is.

1. interior/exterior look and feel
2. small structures
3. medium structures
4. large structures. 

Lets start with the easiest form. The look and feel. In buildings this is 'interior design' and in software its 'user experience design'. Getting this right takes skills, but its the easiest in terms of complexity.

Small structures. In buildings this would be a shed, dog house or tree house. In software this would be a web page.

Medium structures. In building this would be a functioning house, in software this is a functioning application.

Large structures. In building this would be a multi story building, all the way up to a skyscraper. In software this would be a system. Systems are embedded in other machines, like cars and factories, and are operating systems on computers.

How

To create small structures, you don't need too much formal understanding of the architecture, engineering or fabrication techniques used. As the complexity of the technology increases, the level of effort increased exponentially. I can build a tree house, and it will probably stick around for a while, but we couldn't build a 6 story building without some formal understanding of the architecture and engineering behind it. If you or I tried to build a large building without that understanding; the building would probably never get built, and if it did manage to stand on its own; it probably wouldn't for very long.

When

So, how long would doing this take? That entirely depends on the people involved. If you have doing some decorating in a house, or some web pages edits; its usually one person doing it. If you are building a small building or a complex application there will be many people involved; and all having different roles and responsibilities.
Skills are hard to transfer when they are specialized. So, when building a house you would have a plumber putting in pipes and connecting that system together. That person would be good at that, but how good are they going to be at interior design? And vice-versa, would you trust the pipes if they were put together by an interior designer?

Full-Stack/Master Crafts-person

Can one person do it all? It really depends on what you are making, but these people are quite rare. You can run into people that understand the basics; but the actual skills to build that technology aren't the same. 

You may have expectations that one person can do it all at the snap of a finger. That is your personal problem of having screwed up exceptions; and has nothing to do with the people actually doing the building. This happens quite a bit with home renovations. A person may watch some TV and convince themselves that a full kitchen can be done in a weekend. This isn't based in any reality; so those expectations are completely wrong. It's not the fault of the people doing the work, it's a personal problem of mis-guided expectations.

Wrap it up

To build technology takes skills, but it also requires a good mind-set and attitude. Being pragmatic and persistent in solving hard problems is the skill that creates good technology. From the outside, having realistic expectations based on evidence and understanding will allow good technology to be built. The time it takes is how long it takes; no matter how off your expectations of how long it should take are. Those expectations are rarely correct, no matter the technology being built.

Projects and Products

In software development, there is a big difference between projects and products.

A person with enough will and determination can make a project, but it requires professional practice to build a product.

This is true with all technologies; consider the difference between a go-kart and a Ferrari (both are 'vehicles'), or a dog house and a skyscraper (both are 'building'). Lets start with housing.
A homeowner that has some carpentry experience can probably complete a small renovation, and maybe a small structure (like a garage or a deck), but soon the complexity of the project requires them to bring in some help. A real carpenter, who does that sort of work all the time, can come in and complete the same project in far less time with a much higher degree of quality.

How about software? Someone with computing experience can take a course and learn enough rudimentary programming to make a project. A website, or a small app that does a few things. This person, on completing a project, could feel that they are capable of larger projects. This is a trap, with consequences.

What could possibly go wrong? Lets go back to the house example; could the carpenter, knowing how to complete renovations and possibly build a house, build a larger building? How about an office tower or apartment complex? They could try, but the complexity of the situation would overwhelm them, and the result would be unsafe.
This is what architects and engineers are for. The larger building needs civil and structural engineers to make sure the architects plan can work. The carpenters? There will be a need for a large number of them to implement the architects plan and work with the engineers to make sure everything works properly. Everything scales up, but you need real professional practice to manage the complexity.

This is the same reality for software. A programmer can make a project, but it requires a developer with architecture, engineering and programming skills to make a system.

For project sponsors, its on them to understand that a merry band of carpenters, no matter how well intended and hard working they are, will have a very difficult time making an office tower.

This is the bad reality in startups when non-technical people are the sponsors. I have talked to many business stakeholders who simply don’t know the difference whether they are talking to carpenters, engineers or architects. They think ‘developer’ is one thing, and can think they can build a large system with a group of programmers. Things go wrong, and the sponsor just doesn't understand why.

If you are a homeowner, and you think that renovation will take a month; then your assumptions are just out of line, and when it takes 3 months don't feign surprise.

Do yourself a favour and understand your own assumptions of how hard something is are probably wrong. Be pragmatic, and the results will match.