Tuesday, November 17, 2009

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.

Monday, May 4, 2009

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