« Adam Bosworth's blog | Main | Trang Ant task v0.8 »

My personal practices map

JSPWiki: PersonalPracticesMap

In your own time, make a list of your 10 most important practices for coding and design.

Good idea, here's mine:

  • Unit testing (test first)
  • Always be cleaning (avoid broken windows)
  • Eliminate duplication (don't repeat yourself)
  • Seek fast feedback (early and always, rollback in doubt)
  • Refactoring
  • Ask for help (communication)
  • Use many environments

I don't have ten (ten would be too many). But those seven have improved my code more than anything else.

The first three - I don't program too well without them.

As a theme the fourth is most important - take a small step, checkpoint against reality, take the next step. A good version control system helps bootstraps this (and keep a long undo buffer). You also need to inculcate some discipline to work this way - hard work if you're naturally disorganized (as I am, and I do slip). Refactoring is the grammar for a process based on fast feedback. Take those five together and you have a reinforcing and powerful set of practices for better software. Some implicit byproducts are, a separation of concerns, pushing for orthogonality, a clear statment of dependencies, an evolving architecture and a regression test suite. I'm sure there are others. There are two things you get that stand out for me, one micro, one macro. First, the ability to backtrack on changes; it's hard to spin out of control and accumulate bad decisions in this way. When I insist on going Only Forward is when the code gets out of control. The second is an ability to change and adapt the code even as the codebase grows in size and functionality - vital for both your sanity and the economic health of the business. So much code rots and is thrown away because it can't be changed as the world around it changes. What a waste.

And the good news - the rise and rise of the agile movement is going to make these practices as common as muck.

Asking for help is obvious, but programmer culture is so steeped in the fear of seeming stupid it's often a problem (even to be asked). If your shop has this fear, your have a problem no process alone can help with. I've worked any of number of jobs outside IT and I swear I've never seen anything like the faux-machismo that infects developers - builders and bouncers are far better communicators.

The last is maybe the oddest - but it seems the more environments I work the code in, the more robust it tends to be. I think it's a kind of a non-functional acceptance testing that drives out system level bugs, or if you like, exposes the Big Lies.

There are other specifics for Java that have helped me enormously, mostly around organizing projects. I'll write them down soon.


July 27, 2003 01:24 PM

Comments

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1035