Process of Engineering Your Software Product
This article will present you a likely startup scenario that happens from time to time, and this is something Software Engineers Malaysia should be aware of. A bit of a disclaimer here, the author is not saying that this happens all the time and also any monetary and contractual bits are removed from the scenario so that we can focus on the product development itself.
A Typical Startup Story
In many tech startups nowadays, the story usually starts with a two-man team: a Domain Knowledge Expert, and a Software Engineer. Both wants to build a Software and offer it as a Service on the internet. In technical terms, we call this kind of endeavour a SaaS model. There are many Software Engineers in Malaysia too, and most of them will know this story very well.
While this may be the easiest way to start and being human we all understand how easy it is to “get into the moment” and start building stuff.
So, the Software Engineer goes off, starts up his trusty machine and start hammering codes while being in the zone. “Have to put these ideas into something that works”, “Have to put this icon here”, “Have to make sure the button works”, “Have to remember to feed the cat” etc…
Houston We Have A Problem
The problem starts when physical and mental limitations hit someone / everyone in the team, due to a multitude of reasons such as life prioritisation that results in someone pulling out of the team. This can be especially very painful when it is a two-man startup because when either one pulls out, it really means a huge gap left unfilled, and your software becomes stillborn.
- In the case where the Software Engineer who pulled out: maybe the option would be to get the source code from the developer. Then find another Software Engineer to continue the work. However, sometimes it is it is equally difficult to carry on with another engineer’s work because of difference in thought process, technology stack and architecting idea. Ultimately what happens most of the time is that it gets rewritten from scratch, in a technology of their choosing, based on their understanding. Cost: TIME.
- In the case where Domain Knowledge Expert who pulled out: the value might still be there (from discussions), but it is equally difficult for the Software Engineer to carry on. Some prototypes may have useful bits of code that solves a problem, but no further value can be derived since no one knows the domain well enough to sculpt it in such a way that it becomes useful to the intended users. Cost: OPPORTUNITY.
In other words, the quality of your software product becomes questionable, although it is not apparent at the start. This may also happen after the team gets additional funding, and you are ready to hire your second generation of developers to continue enhancing the software product.
Was Anything Documented?
A Software Engineer can come in many flavours. Some are meticulous in making sure at least the code is functioning properly. But it is quite subjective as to whether they use source control and making sure there are available code documentations logged for every source code change?
A Domain Knowledge Expert may know the story from the top level, and know generally the use cases & screens that require which specific functionality. That knowledge is only a hint towards the technical implementations of the Software, and may not be indicative enough on whether a code update will impact any parts of the Software.
Lack of transparency in the development process puts your business at risk. A couple of questions to ponder:
- How will they train the second generation of developers on how to ensure the software does not lose the level of quality promised to the prospects / investors?
- How will they train support staff to manage customer service?
The conclusion is: Software Quality is often not just the “what you can see” part, but rather “whether it is maintainable” parts as well, if a startup is serious for the long haul, it’d better be ready for the ride ahead.
The team should be able to understand the inner workings of the software product well, and able to improve the software product over time. And being human, there is only a limited number of things a person can keep on their minds at any one time.
Ever wondered how to be able to recall the details when it matters?
The Right Way to Start
Every software project has to start with source control, PERIOD. This establishes a comfortable area of transparency where both team members (and subsequently when your team gets larger) will get a bird’s eye view on what is happening to the software product.
Fundamentally, we recommend these basic steps to get started, click on each link to find out how using Visual Studio Team Services (this service is FREE) can help you streamline your startup software development easily.
- Write down what the software actually does and what problems it aims to solve.
- Get your developer / software architect to break down all functionalities.
- Estimate what to build and when to build it.
- Get users or customers to test your product.
- Marketing your product.
I hope this article gives you some insights as to what almost every software product based startup should go through before turning a profit.
To end this article,
“You’ll never get it perfect the first time, but starting somewhere will force you into an iterative cycle of improvement.”
– Luisa Santos, Founder of Lulu’s Ice Cream
Kindly leave your comments if you like to read more articles like these.