• entries
  • comments
  • views


Sign in to follow this  


I may not be some multi-decade veteran of software development (who berates JavaSchool (ok, guilty on this one) and would rather write in a real language like Fortran or PL/X) but I know enough to know that "process" comes and goes like fashion.

Seems that a new consultancy firm or bunch of academics come up with a new best way of doing software development every now and then. There'll be a whole lot of noise, a few high profile dev-shops will pick it up... then it'll probably disappear into obscurity shortly after.

The other thing I've seen with "standard" processes is that they are a perfect example of everything and nothing. You then tailor them for your purpose and team(s) and you end up with your own mix-and-match derivative that isn't really standard anymore... [rolleyes]

Do I sound cynical? Because I'm not, honest - I'm an "optimistic realist" [lol]

Anyway, my employer sent me on a course Thurs/Fri of this week. Was kind of amusing because I got an email last week telling me I couldn't go on the course, which was odd because I never knew I was on the list. The next day I get offered a cancellation and off I go to Sunny Slough...

The course was "Applying the essential unified process," provided by Ivar Jacobson Consulting (Ivar Jacobson's company being the pioneer of unified process, bought about by rational ('rational unified process') and then being bought out by IBM).

Now I'm very aware I could regret writing this in 6-12 months time, but I think EssUP's got something here. There's a certain maturity and common sense aspect that seems to work - less of the "here's our way, the right way, do it exactly like this as everything else is wrong" and more of a "look at what you've got, work out the pain points, here are some alternatives, phase them in and adapt them to suit you"...

I couldn't really do the topic justice to cover all the key points in a journal entry but I do recommend you take the time to check it out should you be interested in such things.

Given that my day job has *NO* development practice, process or any of the other usual niceties I've taken to reading about such things. Too much process can be as bad as a rubbish process, but neither have anything on NO process whatsoever [wow]
Sign in to follow this  


Recommended Comments

The problem is that process should never, ever, ever be applied as one static block. Each development team is different, dammit.

If middle management buys into the "cult of Agile" without understanding what parts of it work for them, then that's even worse than having no process at all.

Share this comment

Link to comment
Yeah, couldn't agree more.

We're quite lucky that they just leave us alone to get on with it the way we want. Therefore I'm putting together a recommendation document for the team to suggest which parts of EssUP will/won't work for us. Even then we'll probably have to refine/adapt the practices.

Share this comment

Link to comment
We used to practice CDD until a few months ago, and now we're somewhere between DBD and the "Decapitated Chicken Process". See here for definitions.

Share this comment

Link to comment
Hmm, that Joel links seems familiar [grin]
I have absolutely no idea what you're talking about... [looksaround]

We used to practice CDD until a few months ago, and now we're somewhere between DBD and the "Decapitated Chicken Process". See here for definitions.
[lol] That's brilliant - I'm forwarding that page to management on Monday morning!


Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now