, 4 min read

What Makes a Good Programming Environment?

Original post is here eklausmeier.goip.de/blog/2013/10-18-what-makes-a-good-programming-environment.


I was recently asked about my opinion regarding agile software development.

I think the core problem is not agile or extreme programming, or object-oriented or structured. I think this simply misses the point. Below are the key ingredients to succeed in software development when it comes to development in larger groups of people, say 3 people and more.

  1. Your edit-compile-debug cycle should be fast. With fast I mean less than a second.
  2. Your build-system (make, ant, maven, etc.) must support the development and ideally only compiles those parts which really need compilation. Use ccache or distcc where required or possible. Unfortunately, some sites simply don't use these build tools but rather build manually. I still witness software development where to rebuild the entire software system takes half a day, fiddling with JCL and various menus to achieve the desired goal.
  3. Your test systems must be easily set up, not just development, test and production. You'll likely need many more, which means possibly many databases, TP-monitors, application-servers, etc.
  4. Your version control system should allow for easy branching, like in Git.
  5. You can easily reproduce version x.y.z out of your version control system or software artefact repository. Do you feel shaky about this?
  6. Your developer hardware should match the task at hand. ("My home PC is way better than my office PC.")
  7. Your test hardware should match the load. ("We cannot reproduce the production environment on test. We lack the data." Does this sound familiar?)
  8. You use a decent bug tracking software which people like to use, not something management ordered you to use.
  9. Identify parts of your system which are mystified, either by dogma or by people, i.e., we cannot touch system XYZ, because otherwise we are no longer object-oriented, or we cannot touch system UVW because only guru ABC knows how to do that.
  10. You need good developers, i.e., people who simply like to code and do this well. Not prima donnas. In almost no other discipline than software development you see such a variety of productivity, i.e., getting results and performance. During my entire career I saw numerous evidence of that. See for example A.M. Pietrasanta: "Two Empirical Studies of Program Production”, IFIP Congress 68, Edinburgh – August 1968, Booklet I, Supplement, pp. I19–I21, for an academic study of this, Joel Spolsky, or Hans Strack-Zimmermann, Computerwoche Nr. 6, 11. Februar 1994, S. 7ff, from a practitioner point of view. Coding times vary 1:25, execution speed varies 1:10 (and higher). You do not usually find these differences in productivity for the exact same task at hand in construction, engineering or sales.
  11. Remove project members from the team which have no proven output or performance, like lines-of-code written, number of defects fixed, number of servers or testsets installed, specifications written. Usually one finds these unproductive or even counterproductive people in various meetings, architecture decision boards, project management meetings, quality assurance meetings, etc. It may look strange at first that you can make a project run faster by simply removing (the wrong) people. Don't get this wrong! You need a strong management supporting the project and the developers.
  12. Measure your performance, either with simple timings or with a profiler. How often do you run the profiler?
  13. Use the proper tools and programming languages, see for example IBM COBOL Compiler. ("We are not allowed to use this.")
  14. Treat each project member with respect. Let them have a nice bureau with sun light, provide a refreshment area with beverages. Let them work from home when possible. You might find this programmer, who outsourced his job to China, interesting.
  15. Use open-source to avoid vendor lock-in, read this article from Linas Vepstas from 2001: The powerful, personal lesson that I take away from this is never, ever use proprietary software for something important. I could easily add reminiscence to this topic where big companies (three-letter companies) failed to deliver their promised or expected support. I understand that there are areas where there simply is no open-source software available, for example in banking, like Bloomberg, Reuters, or Summit. Proprietary software inflicts on you update and release cycles, dependency on other software and their release cycles you may not want to take lightly. Open-source is to a much lesser extent about license costs.
  16. Communicate deadlines clearly and repeatedly. Don't just say: Tomorrow all bugs have to be fixed.
  17. Project funding, stakeholders and stable environment. "Walking on water and developing software from a specification are easy if both are frozen", also read The Impact of Poor Quality and Cancelled Projects on the Software Labor Shortage (dead link).

If you fail on one of these points then agile project management or lead-programmer model or whatever will not fix the problem(s).

What do you think?