(This site links to Amazon or other affiliate links - Info Here )

Friday, August 24, 2018

Stop saying creating software is like constructing a building



Building software is not like building/architecting a home or a building. On the surface there would seem to be many resemblances building software and a building, and there are.  But, there are critical differences that change everything.  (I don’t architect buildings, only software for a living… so if I get building architecture wrong, how about cutting me a break J )


Let’s examine the differences


Static vs Dynamic

Building software compared to building homes or buildings is like comparing old fixed type printers, to moveable type, and these days compared to a word processor.  (Certain things are much easier to do one you can change things extremely easily, changing economies of doing tasks).   They had to plan printing to the last detail early on because there was no choice. (I’m not an expert on printing so if I said something out of place let it slide J )

A building once built is a relatively static object from an architecture perspective, it can have walls and things moved on the inside, additions added within available space.  When architecting a building there is an end goal, a point when you are pretty much done.  With software there often there is no “done”, only done for this release. 



“Infinite” space

Building software is like building a home/building that has seemingly infinite dimensions of space inside.  A building you can specify down to the last nail because you eventually run out of space (most building architects probably stay above the sub-atomic level!).  With software the economics are entirely different with memory being relatively cheap compared to physical space in a building, it’s almost like having infinite dimensions of possibilities. When you finish a room in a building you could paint it, have tables, etc… but physical space starts putting limitations on what is workable to add.  In software with memory being plentiful it always “seems” ok to add another chair table, or even another room inside a room!  In some cases this is amazing, and in other cases this is just a mess in software development (but it is a reality we must deal with) – when you have the ability to construct seemingly alternate dimensions to fit things in your code, things start to be very different than buildings.  (Ok memory is not infinite but you get the point – when you have 4 or 8 billion of something (4GB/8GB), that’s a lot of something!). Go ahead ask your building architect to build you an entirely new building inside your already existing building after it is already complete and make both buildings still usable!

Virtually unlimited dimensions mean it is very difficult to plan for future things or even architect for some changes.  How do you plan for building another entire building inside your existing building?!





Cost/Economics


With buildings there are obvious costs to changing things:

Labor costs

Time costs

Materials costs

Land costs

Space use/limitations

Permits, etc.

With software these costs are much less or at least often less obvious.  Time and Labor costs still exist but most companies don’t employ building contractors year round, they employ them to finish a building and then they are done. (Often developers are employed year round, so the costs are already built in and less visible for labor, only time cost is often visible).  The rest of the costs, materials, land, space are often virtually unlimited or costs economies are so different then buildings you can’t really compare.  (Yes computers cost money)



Base of knowledge

Building architects work from well known bases of knowledge that have been honed for tens of years (and some information even thousands of years – think the pyramids, irrigation/aqueducts, etc.)

They can rely on many things being standard, water pipes, toilets, electrical systems, gas piping.  Rooms typically are …well, rooms.  Sure you can give them some architectural spiffiness but many of the aspects of them stay the same.  Go ahead ask your architect if for every building they architect they need a different sewerage protocol?!

With software almost everything about the next “building” is different, that matters.  Sure on a computer on Windows your network might stay the same (but what is going to go over that network?! – protocols are often different for each application).  On a computer writing to disk is pretty much the same, (but what is the file structure/format?!). 

Building architects have basically swappable materials with known variations for brick/wood,etc. (some more appropriate for one task than another)  But in software we don’t often have those building blocks (Yes an argument for component software but it’s not that easy as we’ll see.)   In software there are many re-useable components but often they are not the meat of what makes your application.  Sure there a list boxes, combo boxes, checkboxes, text boxes, all types of readily available components/controls to use.  But the part that makes your application do something useful is often times new and different, specifically designed for your business needs.  It’s like a super customized building just for your needs, where there are some familiar elements but everything down to even the building materials could be different almost to the point of it being like a building architect, doing architecture with materials from a different planet.  One app gets built with C#, the next with C++, perhaps the next with HTML5.  While they can all produce a “building” (i.e. software product) they often work differently with different strengths, weaknesses – it’s so different it’s like a specialization of doctors from brain surgeon to general practitioner.  Building architects I don’t believe have this level of newness going on in each of their buildings. Software is like one project building a ship, and the next project building a house, and the next one a submarine.  Ask your local building architect to try that!


Ok so maybe you now buy that Building architecture/construction is not like software architecture construction but what should we do to make things better?

Well I certainly don’t have all of the answers, because as we’ve shown software is often different each time.


Some ideas:

Agile vs Waterfall – As noted in the article it is often hard to do true waterfall because unless it’s a contract job, developers are often on staff and need work while the “architect” is still doing their work.  The Rational Unified Process years ago helped start some of the ideas that architecture tasks don’t need to be done before development can start.  Agile went even further.  What is the right answer?  All of them it really depends on the project.  If you are building a fighter jet for contract you’ll probably architect/design/specify as much as you can up front, same for a heart lung machine.  For your little tool app maybe a one line description, TDD, Agile are just fine.  Match your project with your sdlc lifecycle, risk adverseness, costs, structure etc.  At our location we architect the major components and define “just enough” for the team to understand what they are building.  Sometimes that can be a sentence, other times it can be a 100 page document.  If there are components that can be worked on, as soon as we’re all comfortable we’ll give the developers go ahead to implement portions or the whole.  We’ll do iterations of functional versions to demo or release to produce ROI as soon as possible.

Improved languages/tools – In the windows world tools have come a long way since the old vi editors (no flames from vi masters please!) .  Built in refactoring tools, code/object visualization, visual debugging is helpful. 

More common components – Build into the languages similar functionality whether it is observable collections, to common/standard threading pattern support, etc.

Design patterns – Design patterns clearly help start providing a foundation/base of knowledge to work from.  Having languages support standard patterns where appropriate may help.

Common platforms/tools – to allow building a base of knowledge if the ground gets pulled out from under you or changes to mud its hard to keep your footing and build a base of practical knowledge rather than more abstract patterns.  .NET is a nice concept providing a base framework that many languages can run on, providing some commonality between them.

Code libraries – Sure we have specific .dll’s, .so’s or what have you already, sometimes these are generic enough to be used on multiple projects.  Much more of what’s out there needs to be assembled into usable libraries to be available to all languages.  One example was stl for C++ that became the C++ standard library.  Also smaller snippets/templates/patterns of code, design patterns that can be pasted and filled in, and shared with all.  This helps provide some of the standard re-usable building blocks.






 Building architecture and construction is not like software architecture construction:


-          Static vs dynamic/changeable (think non moveable type vs the word processor)

-          Seemingly infinite space for software with infinitesimal costs , not so for buildings real space costs lots of money.  Ask your building architect to build in infinite dimensions, I bet they will look at you funny!

-          Buildings for the most part reach a “done” state, non-contract software rarely ever is really done.

-          Costs/Economics

o   Only time/labor costs for software mostly and labor costs tend to be hidden because unless it’s a contract dev staff developer pay is already built into the companies costs.

o   Minimal materials cost (yes computers cost money but not as much as a truck full of wood, pipes, etc – and computers can be re-used by multiple programs, buildings don’t really work like that)

o   Often times Costs drive action before completing a full architecture plan, because companies are often already paying developers and are not going to have them sit around doing nothing.

o   Architecture is mostly an up front cost for buildings, while it is an ongoing cost for software projects.

-          Base of knowledge

o   Defined inputs and outputs – Your building architect probably doesn’t have vastly different sewerage protocols to worry about.  Every new software product probably does have different formats of data it needs to send or receive.

o   Known materials, tools, strengths, loads for buildings.  A hammer used on one job probably looks a lot like a hammer on another job… but does C++ really look F# and work the same – and could you use each with little to no training?  Not quite!


Summary

While I agree there are some similarities trying to relate creating software to creating a building we can see there are differences so significant to be like comparing apples and oranges, houses and cruise liners... you get the idea.   

No comments:

Post a Comment