Must vs should

 I've been working with enterprises for the past 4 years, with most of my experience revolving around giants. Extravagant revenue, high stability and the budget to experiment. It's amazing, working on the coolest tech, with comfortable deadlines. As a tech enthusiast, it brings out the best in you, exposing you to state of the art technology which may or may not work in the end. But you can always spike on it, because the enterprises have got the appetite to handle failure in case a long haul doesn't lead to fruitful results. And why shouldn't they? They've grown to such a huge extent that it's now a necessity for them to research, experiment and take corrective measure. Take Amazon for example, the fire phone was a miserable failure but it lead to it becoming a leader in voice assisted tech, alexa.

Having spent all my experience in such an ecosystem it was quite evident that anywhere I go I should expect my client to encourage working on tech that's going to help for the next 10 years, but might take a month to implement. Or the fact that CI is a must! There's no point in developing a software that isn't built through a network of a intelligent pipelines where you practically don't have to worry about what's released, how it's released and when should it be released. No matter how much time setting up a CI might take, a week or two, I had to to it as it is the right thing as a developer, and to suggest as a consultant.

But this year's brought a whole new level of readjustments to my thought process. Not that I don't align with whatever I mentioned above. I 100% align to the need of developing a state of the art software with the best practices involved. But what changed this year was the fact I moved on to interacting and consulting with startups up closely. And this time, as more of a consultant than a developer, since startups can't usually afford a highly sophisticated setup, a business analyst, a quality engineer, or a project manager. You're everything, they are everything. Simple. Sweet!

As I went on to having that first interaction with one, I was quite prepped up about how I should gather the requirements, and what should I be suggesting. Let's just assume that the client needed a simple calculator, and if that prototype worked, they'll move on to developing an AI assisted calculator (you do realise I'm quoting an example, right? Lol.).  While developing the prototype of the calculator was an important milestone for me, an equally important part of that process was making sure I setup a CI, an automation suite, IaC, and everything else that I was accustomed to providing as part of good software development practices.

Except the catch here was that it was a startup, and they needed to test a prototype first. Provided it proved to be a success was any effort going to be spent on building a full fledged product. I was in a dilemma for a while, if I should even be suggesting the extras other than just building the core software they needed, if I should be spending additional time on making sure it's 100% tested, and bulletproof. Soon after the first interaction I had answers to my confusion. The need of the hour was to prove the stuff worked, not proving it's bulletproof, state of the art and the best quality software developed by me till now. This might sound quite against the principles I am highly inclined to, but that's the harsh truth. And it's justified. What's the point of making sure your calculator is deployed through CI if at the end nobody would want to buy it after the prototype testing? What's the point of making sure you've spent enough time making sure every leak is covered in the software when it's actually supposed to be a prototype and the only ask from it is to do a 1+1, if it breaks in the trigonometric part, that's okay. Provided you've given enough confidence to the client that what they are visioning is reality, it's okay to live with certain adjustments for the while it's only a prototype.

Moreover startups don't usually have a lot of time at hand, and their time directly relates to the budget. I had to make sure things were built within a week, or two so that they don't loose out on the precious timeline they have planned ahead.

But that doesn't mean it gives one full flexibility to let go of the good to haves. Nope. There needs to be a judicious call. For example if I had to do away CI, I would make sure I setup a simple script that does a very similar deployment that a CI would do, with just a single command. It's not helping the client on the front, but it's speeding my development, and the faster I develop, the lesser it costs to the client. As a consultant it's important to realise how important time and cost is to any client, small or big. It makes a lot of difference if you start incorporating those two factors in every decision you make. It helped me out to an extent that in the midst of delivering the software I had transitioned to a zone where I could just suggest a short way out to the client, although temporary, making sure it doesn't consume much time if I implement it now, and isn't backfiring if it needed to be developed the right way later.

This doesn't mean I've gained what it takes to make the best judgement call. I still get in a thinking mode about what should be done in a call between must and should. And I'm quite sure I'll face such tough calls in future as well. But that's fun in consulting. You're constantly battling between delivering what's right according to your developer persona, versus what's right according to your consultant persona. Trust both of them, even though they're usually quite conflicted lol.

Cheers.