The Fight against Agile Formalization

It seems like a lot of people are just flat out against the buzzword agile and the things which revolve around it (TDD). It's hard for me to take a hard line with either camp, after all, my employer pays me for results I produce, regardless of the methods or buzz I use. But I'd like to try for a moment to speak for these naysayers. Not in support mind you, but in apologetics if my understanding is at all close to being correct.

What software developers seem to hate most of all in this industry of delivering digital goods and services seems to be this:

Being told what to do and how to do it.

This isn't always the case and mostly the two are perfectly acceptable when not joined together. For instance, being told what to do is usually acceptable as without knowing what to do (as in go fix the payroll system) we may not have a job. The how can be more shady in acceptance, but it's not a far reach for a developer to know that to fix said payroll system they need to do it a certain way, but if the certain way requires the sharing of too much detail then you're bordering on micro-managing and that's just insulting to someone with enough intellect to make a computer say "Hello world!" in 30 different programming languages.

This is where the pundits behind agile have had the hardest time selling the manifesto. After all, they don't see that what they are evangelizing is process intensive or micro-management-centric. This is because they understand agile development at it's essence, not just it's definition or the definition of the processes behind it. Some have began to grok this and have taken strides to adjust the face of agile development as it is presented to the process-weary IT staffs of the world. [couldn't find the links I wanted to back up this statement so validity here should be questioned]

The logical, linear, cause-and-effect thinking software engineer hasn't had time to consider the essence of this concept. This is buzz, trending toward that of enterprise vendors selling SOA and web services to inept project managers who put more time into earning their PMPs than understanding what really goes into developing solutions in software for people to use. And not only is this buzz, but you're going to tell this intelligent software engineer that they need to do things a certain way. They need to work with a partner (must not be competent or worthy of trust), they need to always write tests and those tests should be written first (can't trust them to code like a big kid) and you're going to make them work in preset increments of time and make them stick to a schedule!

This is madness! How can a person of average to high intellect and moderate sanity even consider working under these conditions? All they see is definitions and those definitions bullet point processes and if all you can do is fence them in with process it must mean you think they can't function as an individual and after all, all they want to do is write code....

I may be rambling, but I think my point is easy to understand. Programmers don't want to have to follow strict guidelines and commit to too many things because what they do isn't hard architecture where things have been defined for years (a bridge of X dimensions will require Y resources and Z time to complete), they work in the realm of virtual architecture where they like to think things are complicated and undefined and there is no way to know when it will be finished until it's finished.

But that isn't the essence of agile development. So how do you sell essence to a group of people that believe in seeing hard facts but delivering virtual goods? That my friends is a job better left to someone more intelligent than myself, after all, I'm one of the guys you should be selling to.

Just saying.

Code Review without Standards

Code review. Those words get thrown around a lot where I work. I haven't actually been a part of, or even witnessed one, but people at least talk about them. Another colleague who is new here like me said he really wants code reviews in place here. He had that at his previous job and really misses having someone review his work and make suggestions.

One issue that this brings up in this particular situation is standards. This particular team I'm on now hasn't really got any standards in the way they develop. Standard IDE? No. We've got devs in jdeveloper, intellij, eclipse, and for a brief moment netbeans (I had to try ;]). This kind of thing seems like a freedom, but to newcomers and average developers this can be a bit taxing at times plus it leads to little problems that like to edge their way into the mix. How does a person go about ramping up onto the team? If you sit with person-a on Monday and they use eclipse and setup their environment with configuration-b, but on Tuesday you had to work with person-b with jdeveloper and configuration-0 then how productive are you going to feel on Wednesday when you get to setup your own machine? How does one go about documenting a developer ramp-up tutorial? Should you do one for each environment?

That is just a glimpse the ice burg. There are other things like standard code formatting and 3rd party library use vs. reinventing the wheel (how many times should you write a string utility class?) This is nothing new. Every software team across the globe has had to deal with this kind of thing at one point or another. So let me address my questions:

• Can you implement code reviews without first having in place some form of standardization?
• Could code review be a platform from which to define standards?
• Should a standard IDE be encouraged? I shy away from enforcement.
• For those with prior experience in this: How should a group approach implementing standards and reviews? Hoping to avoid making everyone mad.

What say you?

Until next time
Les

For the first time...

...in my life I am actually afraid to change code.

I've been given a task. A simple task:

• add a column to a database table (in dev)
• update the code where that table is queried and inserted into to account for the new column

The rub? There are no existing tests. I have no idea of the current functionality of this code. That means I'll no idea if I've broken existing functionality...

Another win for best practices and another loss for my new job. Unit tests and TDD go a long way to help any, and I mean ALMOST ANY, new member of your team add value to the current system.

No need to worry though, I've been assured by the lead on this that :

Don't worry! It will go to test before it is released!

Why do I not feel any better?

Until next time
Les

Dave Nicolette on InfoQ: A Case for Short Iterations

Dave talks about short iterations:

...the discipline of working in timeboxed iterations is the source of some of the value-add of the agile approach, including frequent and regularly-scheduled demonstrations and retrospectives, a consistent schedule for delivering incremental results, frequent opportunities for customer feedback, and the sense of a "heartbeat" or "pulse" that seems to keep teams engaged over the long haul. [http://www.infoq.com/articles/short-iterations-argument]

I for one enjoyed 1 week iterations vs. the 3 week blocks I did before that. The main benefit I saw was focus and better prioritization.

The necessity of a daily stand-up.

I'm not Certified Scrum Master. I'm not an experienced project manager. I haven't even officially led any team. And honestly other than a short few months at my last place of employment I never really even practiced all-out-scrum.

One thing we did do was a daily stand-up. This daily stand-up was what we called scrum and for the most part that is what scrum is around here. Well here at my new place (the government contract) there are myths of scrum floating around but there is no physical manifestation of it whatsoever. Heck, I had a fellow developer tell me today that their team actaully has a daily stand-up, but he sorta said it through a smile and didn't make eye contact.

What's the big deal? That's probably what you're thinking.

Let me explain.

I've been on-site and billable for about 3 weeks now. I haven't seen any sort of project plan whatsoever. I haven't been given any idea of what our current short-term (iteration) goal is. All I've been told is that there is a trunk and two branches that are being worked on and we plan to get both of the branches merged back into the head.... big freakin' deal.

I'm lost. I've got no direction and no idea what direction the team is going much less any form of idea of WHO is my TEAM in the first place...

And all that to say if they only had some sort of daily stand-up, call it scrum if it makes you feel at home, but some sort of regular, daily, brief progress meeting to give people (especially the new guy) some inkling of an idea of what the heck is going on.

Like I said, I'm no CSM, but I'm going to try and get some form of daily stand-up going. Even if it's just with my leads. And who knows, maybe I'll end up taking it further and getting a backlog defined and prioritized... but that is for another post.

Until next time
Les

Ready for take-off...

...3...2...1

I have just begun a new job working on a government contract as a software developer. The process is very rigid as you might expect from the gov. There have been claims of the use of Scrum but if Scrum is here it's an elusive creature and really I'm afraid that if I've really missed it for these past few weeks then it's bound to jump out from it's hiding place at any moment and maul me to death.

But no, I have not worry of such things. Scrum is not here, nor is any form of Agile software development as far as I can see. RUP is the government approved standard and really it should be renamed to the Rigid Unproductive Process because it sure as heck doesn't seem rational to me and unified is a further stretch with the seemingly endless numbers of silos of expertise, turf politics and the like.

So this new blog of mine will be a place where I place my thoughts and devise my plans for trying to add value to this place. This blog is a pet project. I don't expect to change the world, I'd just like to take strides (even small ones) in order to change my world.

until next time
Les