« Use Cases and Service Cases | Main | ActiveMQ: RESTful JMS, sort of »

Core Software Processes

  • Programming
  • Building
  • Designing
  • Testing
  • Delivering
  • Versioning
  • Changing
  • Automating

Many folks focus only on the first two, usually because their working envionment or software methodology dictates it. The third, designing, is often outsourced to a specialist role (the architect). XP, TDD and other agile appoaches have helped us remember the value of 4, testing. Delivery, versioning and change - not everyone will think these are core practices - often they seem "happen" to us as a result of working on a project over a long enough time. Automation encompasses the special definition of "laziness" programmers develop.

Here's the point. The processes are not something that should be serialized in time order. They should as much as possible be done continuously. RUP folks should agree with this in principle, with the caveat that at certain times we're emphasizing a particular process more than others. Exclusive focus however and we're back to the descredited waterfall model of development where processes are entirely serial ("let's stop for a week to clean the code up", "let's not write any code until we design the architecture", "let's not do any testing until we deliver the code"). Don't go there. The RUP encourages us to iterate the processes, agile methods want to speed this up to interleave the processes.

There's no point just talking about processes - these are things that we do. We might start out being weak at some of them, but that's ok, and it's not a reason not to get started. We get good at a process by practice. The purpose of constant practice is to push the processes out of consciousness and into second nature. So we're freed up to act on the problem at hand in the most effective way.

[tom petty: freefallin']


May 27, 2004 01:40 PM

Comments

Trackback Pings

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