This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Freedom vs. Fear in Software Development Feed Title: David Buck - Blog Feed URL: http://www.cincomsmalltalk.com/rssBlog/buck-rss.xml Feed Description: Smalltalk can do that Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From David Buck - Blog

The second force tries to limit what the programmer can do by imposing rules and restrictions. This force is driven by the fear of what could happen if undisciplined programmers misuse the system. You can't put this object into that variable because it's the wrong type. You can't subclass from this class because it's sealed (final). You can't override this method polymorphically because the superclass method isn't marked as virtual.

The first force tries to make "the simple things easy and the complex things possible" (to quote Alan Kay). The second force tries to make programming safe. In the process, they often make simple things difficult and complex things impossible. Smalltalk has few rules to restrict what developers can do. C# and Java have many rules. Most of these rules are consistency constraints.

In the end, what matters most is that the code works (and can be shown to work by testing), it does what the users require it to do, it can be adapted to incorporate new requirements, and it's delivered within an acceptable time and budget. These are all process issues and should be tackled as such.

Do restrictions in the environment help? I believe that they only help a little and usually cause more harm than it's worth. They increase finger typing, hinder productivity, slow down development, increase refactoring efforts, and decrease code readability

Bad programming practices should be corrected by good processes, not restrictive environments. Bad programmers will find ways around restrictive environments. Restrictive environments just make simple things hard.