Yet Another Programming Blog

Many developers feel no shame when a production bug is found in their code. They ask 'why testers didn't find it?'. Microsoft developers eventually found out some bugs are impossible to spot for the testers. By 1989 the bugs became the developers' responsibility. Developers had to deploy "zero defects" to the Testers. By 1986 Microsoft had explicit monitoring code build into their production code that alerted programmers about bugs. The two critical questions to ask about every bug are: How could I have automatically detected this bug? How could I have prevented this bug? A Hypothetical Compiler  Steve Maguire suggests to turn on all compiler warnings. Today IDEs like IntelliJ IDEA handle warnings perfectly in my opinion. He also suggests to use checkstyle-like tools. Assert Yourself Use debug version of your program to implement assertions. Use assertions to assert input parameters. Use assertions to detect impossible conditions. Write second version of a com

Software Construction The claim that construction errors cost less to fix is true but misleading because the cost of not fixing them can be incredibly high. Construction is 30-70% of a software project. Productivity of individual programmers varies by a factor of 10-20 during construction. Construction is the only activity that's guaranteed to be done. Software Metaphors Advantage of models is that they are easy to grasp as conceptual wholes. Disadvantage is that they can be misleading when overextended. They are heuristics, not algorithms. The writing metaphor suggests that programming is like writing a casual letter. Truth is programmers often talk about 'code readability'. The writing metaphor implies a development process that's too simple and rigid to be healthy. One example of poor advice coming from this metaphor is Fred Brooks' "Plan to throw one away, you will anyway." Another metaphor is software farming - growing a system . You design a piece,