Changing development : Part 1
A rolling stone gathers no mossChange .......... well it's either something you like, dislike, can or cannot deal with ........ so it's like most things I suppose, a fairly cyclical arrangement but always present.
Lately I've experienced a fair amount of change, and have found myself in a new position which is both a change for me and a role where I have to effect change, lots of it, near constant evolution at that.
Changing the outcome of a development process that is; but not by defining the outcome any more (using power point or buzz words or the latest "approved" process). But by effecting the manner in which things are approached (done) by people.
Bit like golf and the approach I'm guessing.
Quality software is the name of the game, not short term money ........ or more importantly, not getting called at 2am because the servers blew up or are failing under load.
Or your entire user base (or dev team) leaving as quickly as your projects flees from doing things the right way (be that out of panic, greed or not knowing how to strive for quality).
Where you are, not where you've come fromFew things annoy me, though finger pointing and blaming others are quite high on the list.
I rarely care in the moment about much of the history leading up to how a system evolved, most developers try to do the best they can in the moment, in the situation they are subjected too. Hence saying X did Y and is pointless, serves no purpose other than to add to the distraction and annoyances.
That said ........ what is actually important is being aware of what you actually have and what state it is in.
Reacting to what is thought to exist by guessing at some symptoms, will 99% of the time make it worse, I don't want to think about the number of times I've seen that one and decisions coming from "Oh I thought it was slow due to the server opposed to inefficient code."
So step 1 as a wise person once said "Don't just do something, stand there" resist the impulse to rush in a "fix" (a.k.a. mess up more) what is there.
Whatever it is, will likely be there in a short time once you've thought about it and then you can deal with it.
Where are we goingStep 2 seems to follow step 1 nicely.
Now we know where we are, we can then think about how to get to where we want to be. Simple enough, though getting people past step 1 is likely the hardest bit.
A bit of creative destruction is typically needed.
Running on broken legs is quite hard, much the same as working in chaos attempting to build anything of stability. Let alone being told to run faster or with other people who are crashing into you, when should all be helping each other.
Some tools can help, task/project tracking, version control and coding standards are a no brainier these days (I like Trac for instance, SVN, phpunderControl, phpcs, etc, ).
But just having them is nothing, that they are used and serve a useful outcome is the point.
Nothing is a standard or "accepted" until .......... well until it is, i.e. used daily, familiar, accepted and part of how things are done.
Then you can talk about having a standard or "process", until then you are experimenting or adapting the tools to the situation and desired outcome.
Learning to walk in step will seem strange to people who are used to walking around on their own, though when you have to walk with a team (let alone run) there are better ways of development teams working together.
I usually think about flocks of birds or any natural system, mother nature has put the writing on the wall in 500ft tall neon for us ....... personally I shut up, watch and listen to such patterns and complex systems that appear so simple, how do they do it ?
Just about everything we do is interacting systems, they just need a bit of tuning ;)
Hence where the cycle of development comes in, it's flat and flows between each area, idea->design->dev->stage->idea->etc ...... and so on, with what ever steps relevant to your situation.That can either be progressive or agile etc.
Guiding momentum in such a way is always fun, though once it's going and speeding up, just stand back and grease the wheels occasionally :)
Sounds like a dream ? ....... maybe for some, though not one I accept as unachievable, I've experienced and been a part of it too often.
Juggernaut development teams know what I'm talking about. Brownie points for knowing where that reference comes from.
Are we there yet ?Good old step 3 ...... coming to terms with the fact you never get there you just succumb to continuous integration and accept a permanent state of improving the software (call it perpetual beta if you want), and that all things in life go in cycles and evolve, some bits die some get stronger, but given momentum they carry on.
Jan 2010 http://www.phparch.com Magazine had a good article about Going Industrial
The actual steps I can comment on later :)
Lets build Austin Martins not Trabants people !
1. Asses the current state of development & tools before acting
2. Find out what the actual outcome the team & company want
3. Align the team the common goal
4. Get the correct tools (and process, though process is just a social tool after all)
5. Hold off "management" by explaining the process of change
6. Have the confidence to allow it to happen opposed to pushing too hard