A learned eye can make out the issues in workmanship of software applications, from even a casual glance. The issues are not only skin-deep — in the sense that they are not only user interface related issues — but they may run deeper in the core of the application’s design or architecture.
Ever noticed that the workmanship issues are high in the software catering to some domains as opposed to the others? Think of disciplines such as Chemical Engineering, Astronomy, Legal, bio-science or some other arcane domain such as non-Euclidean geometry, Financial analysis or even Politics.
In some extreme cases, the lack of sophistication would be evident right from the basic web design. In the world of beautiful websites decorated with the latest fashionable ornaments, you would find the sites pertaining to these domains quite arcane, if present at all.
Is it hard to make software for these domains?
But then look at domains like education, social media, advertisement, e-commerce or real estate. There is plenty of decent software catering to those.
How do you explain this difference?
It is also interesting to observe that there is also a direct correlation between this workmanship and number of products available in that domain. The more the number of competing products available, the better is the workmanship.
Software is written by the programmers. People from other disciplines have not been able to participate in software development, and so haven’t been much influence on what gets developed.
Therefore, it always comes down to what the software engineers understand better. The more a domain is felt closer by the programmers, more programmers can develop software in that domain, improving the number of options and the workmanship of the software both.
What is true about the various disciplines is also true about the advanced software technology that has evolved (often called as deep tech). Today there aren’t many software programmers who understand AI / ML, data science, cyber security or some other esoteric algorithms. Therefore, the demand for manpower trained in such skills is far higher than what is available. Also, this manpower is quite expensive — so much so that getting such a full-time expert on a project team is not financially viable for most projects.
All the existing software is created by polymaths — programmers who also understood the other domains. As the domains get more and more specialized, there is more and more pressure on these polymaths to learn more. This is not sustainable.
The Solution: Distributed Development
Acism specializes in using Xsemble technology, which supports distributed development. Programmers are needed for implementation of individual components only. The overall flow can be managed without programming.
There are two ways in which this helps solve the problem.
Domain Experts Work as Assemblers
As per Xsemble parlance, Assemblers are those people who look at the overall flow of the application. Their work is mainly to deal with visual components, and it does not involve programming.
With a little training, domain experts can be turned into Assemblers, so that they can visualize the software application, and create and maintain the flow diagram accordingly, on their own. From their work, the requirements of component implementations emerge.
Most of the component implementations can be created by programmers who may not have expertise in that domain. This is because by definition, a component is tiny (molecular level as we call it), and therefore it is very easy to understand enough to code one component.
Instead of trying to train the programmers to make them understand the complete domain, the domain expert may just sit with the programmer when a component is assigned to them and tell them what should happen inside that component.
This saves not just the training cost but also allows you to use programmers from the vast pool of programmers that is available.
Expert Programmers Used Sparingly
Xsemble allows selected components can be exported out as separate “test bundles” which could be worked upon in isolation.
For the components which necessarily need a polymath expert programmer, we use this model. It allows the engagement with the expert to be crisp, and limited to those specific components.
Companies can utilize this model to use the limited bandwidth of the experts to contribute to more projects. On the other hand, the expenses are limited when the expert is engaged on a contract basis because of the crisp engagement.
Handling Large Engagements
Acism uses the same distributed development model to handle larger engagements. It does that through involving external contractors / students to work on individual components.
Because of this model, Acism can scale up its project team and deliver much larger projects than what our inhouse team alone could handle.