Building a Product

During my education, I’ve always tried to keep myself busy with side projects. These projects involved entrepreneurs reaching out to me with an idea which I would help them convert into a product or a development strategy. I feel like I’ve learned a lot through these projects while working on them and actually even more when I learned the correct way of doing this during my Masters in Software Engineering at CMU.

Formulating the idea

Being an absolute nerd, once I hear a tech idea I’m really excited to jump into technical system designs. I would usually jump into thinking about the tech stack, hosting requirements, development timeline, etc. While being able to work out these details at a very early stage would really excite my clients, the ‘Software Requirements and Verification’ course at CMU made me realize that this wasn’t always in the best interest of the client.

I learned quickly during the course that in the early stages of product development it is important to focus on the ‘what’ rather than the ‘how’ of the idea. User validation is more important than people think it is. The ultimate metric of the value of your product is the consumer’s experience. Mocking and prototyping is an opportunity to get a sneak-peak into the future of your software. I get it, it seems rather mundane to invest time and effort in building semi-working pieces of software. But get this, the cost of changing a prototype based on user feedback is the price of peanuts as compared to changing something about the product once it has been rolled out as an intricate software system.

I remember spending most of my development time on making trivial changes like ‘making the red a little more red-er..’ While this is super frustrating for developers, perfectionism in visual appearance is something that brings immense joy to the client, and if done thoughtfully to the end-users as well. I wish I had spent this precious time tweaking the performance of my SQL queries and making the user experience much better. Changing the black color in Balsamiq would’ve definitely been more fun than changing the hex code values in an Android XML file.

Scoping and Planning

Being ambitious is great, but for entrepreneurs who are on a tight budget, this could be dangerous. It’s really tempting to go overkill on that first launch when you want everything in your head to turn into reality. But software development is an iterative process at its core. As a general rule, going too broad on the feature set inadvertently causes a drop in overall quality/reliability. It’s better to have a working product with fewer features out there rather than a huge cartload of junk features. I learned this, of course, the hard way.

While planning ahead is great, expecting things to go exactly the way you want doesn’t always do you good. Resilience is an important attribute of a good plan. Estimates of effort, time, and cost are heuristics that develop with experience. Effort especially is a little tricky as for most projects you end up delegating work and that no matter how good your recruiting skills are you’re going to end up with diversity in skill levels and thus in the time taken to finish assigned tasks.

System Design

System design is a hard problem to solve because it requires some amount of foresight into what your problem space may look like in the coming few years. Something as basic as the choice of Database may change the course of the product a lot. Having multiple databases seems like a wise choice but you need to remember that there is a cost associated with their maintenance and development. Even setting up the ORM entails a cost. Sticking to something basic in the early stages may speed up development and make development smoother. While deciding on a database, think about the querying mechanism rather than data visualization.

Have plans for sharding and replication in your infrastructure at the beginning, this reduces migrations costs a lot. Businesses tend to exponentially expand data storage in the early phases because of the large effort being put into promotions.

Cloud infrastructure is largely inexpensive these days and is the best way to go in most cases. Sticking to basic instance hosting solutions rather than hosted services helps you jump from provider to provider with minimum friction.

Stack selection is a pandora’s box on its own but the key things to look into are the front-end vs back-end processing loads, complexity, modularity of functionalities and ofcourse the availability of skillset in the market.

Code Development

Once the infrastructure is more or less in place, the implementation usually kicks off based on use-cases. Having well-defined flows, in this case, is really helpful. Agile methodologies are tested and proven however the success depends a lot on the definition of the sprints. Having prototypes already figured out before code development begins usually comes in handy in giving the team a crisp definition of a use-case.

Testing

I’ve suffered time and again for not putting enough effort into testing, and once I started using them as a way of thinking things went great. I’m not a fan of TDD(Test-driven-development) because it largely slows me down, but the more familiar I am with the mocking framework, the more scaffolding I have to come back and write adequate tests for the module I’ve just built. Also almost every time I catch a bug in my code in prod, I add a test case for it to develop the brain-muscle memory for the test case.

Doing run-throughs of a flow is extremely critical because this is how any assumptions are caught. Assuming the user will think or act in a specific way is a great recipe for disaster. You’ve probably heard the QA tester walks into a bar joke…

Feedback

Although a very annoying process to go through, feedback ensures and almost always improves the quality of the product. I strongly recommend against face-to-face feedback sessions except during a run-through. It is hard to take criticism about your code on your face and unless that is a skill you are actively working on developing, resort to written feedback or any form of asynchronous feedback. It gives you more time to think about the perspective of the user rather than it feeling like a critique on your work.

These are some learnings from my mistakes that I would love to share with my fellow developers.