[debarshri]

I think there's always argument that you don't know what you don't know. How much thought do you put on writing code with out bugs. Bug could be caused by the business logic, the language internals, the runtime environment internal and variation. I think what people often ignore writing piece of software is an iterative process, you build, deploy and learn from the operation and you fix and repeat.

If you keep thinking of all possible issues that can happen that becomes a blackhole and you dont deliver anything.

[swatcoder]

> writing piece of software is an iterative process

Often, yes. Absolutely.

> you build, deploy and learn from the operation and you fix and repeat.

But no, not at all in this way. This is generally not necessary and definitely not a mindset to internalize.

Commercial software products are often iterative, especially for consumer or enterprise, because they need to guess about the market that will keep them profitable and sustainable. And this speculative character has a way of bleeding down through the whole stack, but not for the sake that "bugs happen!" -- just for the sake that requirements will likely change.

As an engineer, you should always be writing code with a absolutely minimal defect rate and well-understood capabilities. From there, if you're working an a product subject to iteration (most now, but not all), you can strive to write adaptable code that can accomodate those iterations.

[swee69]

> As an engineer, you should always be writing code with a absolutely minimal defect rate and well-understood capabilities.

I think the problem with the purists is that this is just a moral claim - it's not based on how businesses + marketplaces actually work. The lower you attempt to crank the defect rate (emphasis on the word "attempt"), the slower you will iterate. If you iterate too slow, you will be out-competed. End of discussion. This is as true in open-source as it is in enterprise SaaS. And in any case, you're just begging the question: how do we determine the "absolutely minimal" rate in advance?

> you can strive to write adaptable code that can accomodate those iterations.

This is a damaging myth that has wasted countless hours that could have otherwise been spent on fixing real, CURRENT problems - there is no such thing as writing "adaptable" code that can magically support future requirements BEFORE those requirements are known. If you were that good at predicting the future you would be a trader, not an engineer.

[debarshri]

I mostly agree with you.

In first few iterations of writing the code, you often don't have complete picture of capabilities, capabilities change on the fly dictated by change in requirement. There is no baseline of what minimal defect rate it. Over period of time and iterations you build that understanding and improve the code and process.

I'm not saying that you don't think before you write code but often over thinking leads of unnecessary over engineering and unwanted complexity

[hulitu]

> I think what people often ignore writing piece of software is an iterative process, you build, deploy and learn from the operation and you fix and repeat.

I presume you didn't use any Microsoft operating system (or program). /s