s/w product development and the building block analogy

Developing a software product is akin to building a house. You have a plan when you start building the house. With computer models, you can pretty much visualise the entire house, space, things that will be there like sofas or ward robes or others and get a feel for the entire house before you construct. 

Why is it not the same with software? We still have this practice of drafting requirements in English which the author himself would find it hard to read after it is written. 

There are models based on UML as well which may be better than text. There are user interface mock ups which give an idea of the front end. But still the programmers who are essentially the masons and carpenters and plumbers of the code that builds the product has no way to visualise the entire house the way the plan shows. 

You may say that the masons of a real building may not know the entire thing and it is the civil engineer or the architect who has this mental model of the entire building. Agreed. But this is where a big hole is left open in software. Building a wall which forms part of a bigger plan is known up front when a building is constructed. However, in software this is not really true. The reason being the requirements themselves are vague many a time on a document. Further, the design based on UML or other diagrams are not frozen before coding begins. Though the waterfall models strictly mandate this, there is always a overlap of phases and with agile models and go-to-market strategies things have gotten really worsened to the point that you often end up scrapping the whole effort done earlier to begin a brand new build out. And we come out unscathed giving justifications for such acts eventually growing the mistrust on the programmers guild.

The biggest difference I see is, the requirements for a building are easily visualisable. And hence a wall that is done somewhere in one corner of a building is easily visualisable as well. If we ask why requirements for a building are easily visualisable, it is primarily due to the fact that you see houses all around you all the time. People right from when they are kids have a sense of buildings around. They play with building sets, they build castles on the beach sand and we live in them. So the sense of buildings are easily ingrained in us. It is not something like an effort has to be made to bring it into a visual form. Of course, complicated structures, aesthetics and so on may require hard thinking. But a engineer or an architect can do this in his head and bring it in a virtual reality model using a tool that can be seen and visualised easily by others. So it is easy to freeze the needs between the consumer and the producer.

If you take the case of software, the consumer varies in degrees in terms of the knowledge of the domain and may not know what software can or cannot do. Same is the case with the software guy who does not understand the business side to be able to speak that lingo with the consumer. There are nuances in every domain which only the experts in that domain understand. It is mostly a case of people, processes and the way businesses have been going on which is what the software tries to replace in parts or whole. How do you model this like the way you visualise a house?

If we take the different components of a software, each of them may expose interfaces for a consumer. Say, we are designing a software that brings together people in healthcare like patients, doctors, hospitals, diagnostics labs and so on into a platform where they exchange things. Now to solve this, if a graph database was chosen, which exposes APIs that allow the user to add, link , traverse and so on. All of this makes sense for the software guy. But how about the healthcare folks? 

If there is a visual representation of the 'business data' of the health care domain shown to enter a box representing this graph database and the data coming out of it or the ability to see the connected graph of the business information for one or more use cases that is produced as a result of interaction with that box which is the graph db, then everyone involved including the person constructing it will not miss the point. However, this can still be missed by the domain people who do not get what a graph db is or how it helps their case. How do we bring these two people together? 

This is where I feel we can use the analogy of a building itself which is familiar to both the parties and which in parts can be likened to software construction.

What I say here is a sort of convergence of the business domain and the software architecture / design. The software architecture is not done by having components and connections and interactions and flow diagrams independent of the domain experts. The business domain experts can make sense of the flow of the information into the 'user interface' which is the most visible part and be able to see changes in the user interface. 

The underlying parts which result in the computation are all now shown as a person walking in a house from one room to another, from one floor to another and coming out. It is sort of a model of a house with floors and rooms where the data payload is a person who starts somewhere say ground floor in a room which is akin to the component that exposes a REST API and starts going into the different parts of that room say cubicles that does some transformations to the payload which is the person himself. The person's look and feel changes as he walks through cubicles and rooms and floors which are the different layers of the software. The person may grow in size that is akin to the payload growing while traversing a room of a certain layer for example. The person may come out of a cubicle or a floor or a room based on O(n) computations that happen within them. If he takes more time, we know there is a large amount of computation necessary or unnecessary as a next step. 

This kind of visual models like a house, building and people where we are more comfortable to associate with than the flat diagrams with its own notations can often give a quick sense of what is going on for every one right from the business folks to the coder responsible for a module. I some how feel that this can be done with Lego bricks. The only difficult part is the morphing of the person walking along as he visits a room or leaves a floor with the computations or impacts created in that place. Even if there is a 3D model of this in software it looks like a interesting and highly potential software tool that can pretty help to accelerate the way we architect software in the future. 

How SMBs can grow bigger?

I have spent a lot of time observing the way small businesses work in the Garment sector in Tirupur, India. There are 1000s of small and medium sized units that churn out millions of T-Shirts, tracksuits and the likes in a day for their customers predominantly in the US, Europe, Japan and others.

For an outsider, it is a wonder how these units work together to come out with a shipment that includes quality checked products. It is a massive team effort crossing different skills, different domains and different cultures to mass produce, ship from India and sell them in Europe.

Communication happens across board right from physically visiting a 'Dyeing unit' to check whether the cloth that was given for a certain order has been dyed to electronic medium like email, voice, spreadsheets, specialised Apps for communicating the designs, optimising the cutting of the reams of cloth or making the designs on the T-Shirts like embroidery or printing and so on. There are innumerable possibilities that arise with every order which can be as crazy as a certain type of button to be fixed somewhere near the pocket with a certain size and colour. I am just sounding an example to show you how 'things of art and fashion' identified and designed by some one , some where in the world is translated to 'things of labour' and 'mass production' and the numerous steps involved in getting them to be shipped finally.

I believe the above is the nature of most of the SMBs in various other domains, be it, ancillary parts manufacturing for automobiles or even a logistics company sending off its trucks to deliver goods. They all have innumerable interactions every day within the business, across businesses.

Many of these SMBs go through the cyclicals in revenue realisation, labour management or government policies on exports or others. Because of the ups and downs, the sector (mostly from what I have seen in India) is highly unorganised, chaotic and most often huddled into groups that support one another informally often disallowing new entrants.

Most of the SMB owners (at least the ones I have seen) are not tech savvy. They absolutely rely on paper and pen and mostly memory for information management. They appear with flashy phones and tablets mainly to show off their status in a business meeting with others. But the owners are completely ignorant of how software can be used to scale their operations.

It is also partially true that the software folks who have created things for them have failed to understand the exact needs that would make the life of these business owners easy. Many a time, the software is extremely unfriendly with 100s of options and features and menus that acts as a deterrent. On the other extreme lies SAP which covers a lot of ground, but again lacks the ease of use or the tons of configuration to set it up apart from the cost. Custom software suffers from too much of pointed solutions often requiring the owners to go back to the software company to keep patching things. The tools that seem to be used widely are Email and spreadsheets and PDF files.

It is very clear that a lot needs to happen here. Especially software that is not as hard and pricey as a SAP while not as specific and patchy as a custom build or as generic and lot of labour like Email or Spreadsheets to come to the rescue of these people.

Collaboration like a social networking tool, Organisation of information and retrieval for both structured and unstructured data from documents to pure structured business data that can be done by any one easily like the way they organise files and folders in the paper world but having the advantages of a digital world which can relate things and search or query, access controls at different levels within and outside of the business and discretion in sharing of information....

This is a serious want, a big want and a complex one to accomplish.

This can alter the way SMBs work enabling a whole new information supply chain, taking to a new level the scale and mainly ease of doing things. A tighter integration of information and data collaboration and standardisation of processes and communication across the loosely coupled SMBs can make them suddenly look like a single entity that can stand up to challenge larger businesses. This is a great model to achieve as it has the power of loosely coupled independent entities that are geared to achieve bigger goals.