Prologue
Here is the gist of a conversation we had with a prospect – a budget-conscious startup. (The prospect is now a client.)
Q: How much would it cost to make this software?
A: Around 7-8L
Q: Well, that’s a lot for our company to shell out. Is there a less costly way?
A: Yes, the other extreme is a DIY mode using Xsemble, where you use your own team members. In fact, if they have better handle on the functionality, then they will be in a better position to draw up the flow diagram. Assuming you get innovative about coding components, say by employing students as interns, your cost factor reduces drastically, while the management overheads will increase. In terms of cost, you are looking at under 1L, majority of it being Xsemble license. You do not need to go for a paid training as long as your people are okay to read the documentation.
Q. Just 1L? That’s wonderful. I’ll go with that. However, since I do not have any Java programmers with me, what can we do to reduce the risk?
A. Sure, you can take one developer on contract who knows Java and Xsemble both, and that will help you reduce the risk.
Q. Perfect. Let’s do that. Let’s cap it for 3L. Do you think it’s possible?
A. Yes.
The Challenge
Projects differ widely, not just in their work content but also in terms of their expectations on project performance parameters. On one hand there are projects to quickly build throwaway prototypes, and on the other there are mission-critical projects that demand a rigor in the approach.
In practice, these project performance parameters –such as quality, risk, speed, maintainability– are traded against the project budget, knowingly or unknowingly. Project decisions such as how rigorous documentation is produced and maintained, or whether unit testing is done and how work towards that.
What Acism brings to the table is a factor that has a far larger impact on these equations, with a desirable side effect.
The Solution: Work Restructuring
Acism specializes in using the Xsemble technology, which allows a clean bifurcation between the two roles:
- The Assembler: The Assembler is a citizen user who understands and manages the overall flow of the application. The Assembler does not need to possess programming expertise.
- The Developer: The Developer is a programmer who delivers individual component implementations.
Let’s see how this relates to the project budget.
Keep in mind that the costs of services are in proportion to the effort expended. While the effort saving due to the use of Xsemble technology effects in the overall cost reduction, further cost saving can be achieved by deciding on what you outsource and what you don’t. In other words, the more you go the DIY way (Do-It-Yourself), the more you cut your bills.
So, what can you do yourself and save cost? Almost everything, as it turns out. The good thing is that this works even when you do not have programming expertise within your company.
Details into the DIY Work
Consider the individual work profiles:
Development
The most prominent shift from the conventional role of developers is that the developers are needed only for creating components. They are NOT needed for assembling them together. You may consider the bifurcation between a team of core developers and the rest as satellite developers. The core team is roughly 1/5 th of the size of the developers’ team that you would otherwise need. Their main job will be to evaluate the component implementations contributed by satellite developers. The satellite developers can be loosely attached to the project, and keep working on components assigned to them.
Depending on what kind of programming resources you have, the core and satellite developers can be identified. Costs can be saved amply if you can use students / inexpensive freelancers for development. (It will increase your management effort though.)
Assembling
The Assembler’s work is best managed by someone who understands the domain well. As said earlier, an Assembler would not be required to do programming, but own the software flow diagram.
Costs can be saved when you take up the Assembler’s work yourself. As such, you understand your domain well, so this has a desirable side effect that you save on the overheads of providing deep domain training to other people.
Testing
You save on the testing cost if you undertake to do it yourself. However, please do not ignore testing. Acism preaches and practises the Agile iterative development approach, where incremental releases are released periodically. If you follow a practice to test these incremental releases, then the product is almost entirely tested by the time it gets developed.
Unit testing is carried out by developers themselves, by writing programmatic unit tests. With Xsemble, the test case templates are generated for the programmers. Also, when you use the approach to outsource the development (especially to satellite developers) in the form of test bundles, then they can test the implementations only through writing unit tests; so in a way unit testing is implicitly imposed with the test bundle approach.
Management
You can own the management through planning and monitoring the project progress against the components. You can do a great job in managing the schedule and budget by keeping tab on the team deliverables, and scaling up or down the team as needed. You can manage the risk by using the Xsemble flow diagram. This flow diagram is an accurate and explicit representation of what goes on in the software, and so it may be used to identify any potential challenges. You could share it with stakeholders early on and get them on a same page.
Support
Typically, the Level 3 support function is technical and requires a good understanding of how the software functions. You could teach your support personnel how to do a live visual monitoring of the Xsemble application and enhance their effectiveness in addressing the customer issues. (This does not need programming.)
If you get to a point where a fix has to be made to the software application, you would have identified the defective components with visual monitoring before inviting a programmer. The programmer will need to fix only those components, and not concern themselves with the rest of the code. The study required is orders of magnitudes smaller. There is a potential to save costs here by not having to maintain a dedicated team of programmers who understand the software application, as even a new person would be able to manage component level work.
Summary
We bring to the table a unique approach which delivers a lot of flexibility with respect to the structuring of work. This flexibility can be adroitly exploited to tune the budget, specific to a project requirement.