Why I miss my coding days

These days I often miss my coding days.  I miss the joy of putting things together and running it.  Building something with your own hands and seeing it taking a life of its own are very rewarding.  There is enormous satisfaction in seeing what you built is used by people.  It's something that you are not going to be able to describe to someone who has never coded.

Now that I have made transition to Product Management team, I rarely think about coding as rewarding and fun process.  Rather as business unit I think of coding as something to get through.  An obligatory time that you have to spend with developers to make sure the core requirements are met, and user experience stays as originally designed.  Development time is considered as long pole in time-to-market that needs to be crunched up to get to the market faster.  Business owners are incentivized to cut down the development time.

Business team understands cost, schedule and feature scope;
but quality is something that engineering team has to control

I think it's largely because of difficulty in articulating what a product quality really means, and lack of good measurements to get a good feel for the quality.  While quality is difficult to understand, time and cost are very easy to quantify.  This lack of quality measurement ends up driving the business decisions in favor of reducing the time and cost at the price of quality.

Problem is that quality can mean lots of different things.  Quality could mean the low number of known defects, graceful handling of failure case, scalability and easy extensibility.  What's worse is that these quality measurements are not visible when you look at the final product.  Just like you don't see how foundation is laid out by looking at the finished building, you have a little idea how well product is constructed by looking at the UI or how well it runs during functional testing.

Quality product is built with common use cases in mind.  To extend the building analogy, good builders think of earthquake proofing, heavy rain or snow, and insulation against extreme cold or heat.  Same is true with writing software.  Unless you think about those expected cases, you will not have quality software.  Under reasonable conditions, product just gotta work.

This is a part of reason why it takes long time to release a product versus building a prototype.  It's because there are many things to think about when releasing a product.  Delivering quality product is not just implementing the requirement provide by business team.  It requires developers to think about all the other reasonable assumptions, and writing software against them.  It's about choosing the right way to implement instead of writing something that runs.

Business folks won't be able to clearly articulate quality because there will be too many cases to articulate if all reasonable behaviors to be listed out.  But that should not mean developers can take shortcuts in writing code.  That's because only developers can really control the quality of product.