small medium large xlarge

Back to: All Forums  PragPub
Nik-head-1_pragsmall
16 Nov 2010, 00:55
nikolaus heger (12 posts)

Reading a lot about agile methods in the magazine, I am wondering why it seems so far removed from my own day to day experience.

The thing is that programming is in some ways an elitist profession. Good programmers are hard to come by. Mediocre programmers are everywhere. The latter would benefit from reading The Pragmatic Programmer over and over again, until it sticks. Agile methods are great but in my opinion personal skill is way more important to determine what gets done and what doesn’t. Ive yet to meet a programmer who didn’t say they followed agile principles. Then when you look at their code they have never even heard of DRY. Basics!!

Most do the first thing that comes to mind, and when that doesn’t work out they add band-aids until it works. Mostly.

So all in all - agile methods are nice but do they make the individuals better at what they do? Because that - and not methodology - would be my primary concern.

Generic-user-small
14 Dec 2010, 03:12
Robert Stackhouse (12 posts)

Nikolaus,

In my interpretation, agile is aimed more at the organizational issues of software development (assumes you are not developing software by yourself for yourself) rather than the technical ones. Where agile calls out technology or technical prowess (i.e. “Continuous attention to technical excellence and good design enhances agility.”) it does so in support of the organizational issues.

I speak from experience when I say that if the organizational issues aren’t taken care of, it doesn’t matter how many excellent developers you have on staff.

Although the two are definitely connected, I think you are conflating “agile” with “software craftsmanship”.

It sounds like the trouble you may be suffering from is that people talk the talk rather than walk the walk. For the band-aid crowd, organizational “urgency” may be getting the better of their judgment. Alternatively, if they are doing TDD, they may never be getting back around to the “refactor” part of red-green-refactor. I don’t think that just because you find duplicated code in a code base does not make it fair to assume that someone has never heard of DRY. I’ve known harried developers who understood that DRY was important, but clearly received the message from their organization that code quality was not to take precedence over turn around time. Any developer worth their salt knows that this is a short sighted approach that it will lead to longer turn around times as the code becomes increasingly spaghetti-fied. However, understanding a thing and communicating a thing to closed off management are two different things.

I went to an agile conference once, and I talked to a number of people about the closed minded-ness of the organization I was a part of at the time. They all had the same advice: invoke the law of two feet (quit that is). Easier said than done in a time and locale amidst a job shortage situation.

If you really want to see change, I’d focus on creating converts (that is showing rather than telling people why they should change) as this book suggests rather than damning people for their lack of good development habits (some people just don’t know any better or feel it pointless to do the right thing). You might also do well to read How to Win Friends and Influence People.

A parting thought from Ghandi, “Be the Change You Want to See in the World.”

Generic-user-small
15 Dec 2010, 00:09
Mike Abney (1 post)

You’re both right. The people are the most important. There’s a reason that’s the first value in the Agile Manifesto. Good people can overcome bad process. However, we get better products when they don’t have to. That is, good people can write good code, but without a solid idea of what they are building and why, they are very unlikely to make a good product. Most “methodologies” focus a lot on how we determine we are building the right thing. XP is really one of the few to focus heavily on the technical aspects. This is probably one of the reasons why (at least early on) it resisted being called a “methodology”. And the combination of these is likely why Scrum and XP get paired up a lot.

Generic-user-small
15 Dec 2010, 04:08
Robert Stackhouse (12 posts)

I’d have to wonder if I did my job as a software developer if I did a really good job at building the wrong thing.

Picture_14_pragsmall
13 Jan 2011, 19:16
Tim Ottinger (6 posts)

Niklaus, et al:

Agile methods are about peer mentoring in a big way. Most slapdash programmers have never had the opportunity to learn from masters of the trade, and find fundamental software concepts to be academic concerns far removed from their daily experience, as you have noticed. There’s a lot of head-nodding and label-wearing, but sloppy coding is if nothing happened.

We’re trying to fix that.

What Jeff Langr and I do is summarize and present complex topics in a small format. We decided that we could present the four most important concepts of software development in four articles (one a month, starting last December) and that these articles can help software developers come to a better understanding of the goals and end points of refactoring, clean design, testing, and the like.

We are on the third of the series discussing Coupling, Cohesion, Abstraction, and Volatility. Please feel free to comment on our articles, argue with our exposition, suggest improvements, tout, or publically ridicule our work as you see fit. Our hope is that it will prove valuable to programmers whose first need isn’t agility, but basic competence in the physics of software development.

When we finish the four-article series, we’ll return to agility but hopefully in a way that can touch your daily experience more meaningfully.

Tim Ottinger

You must be logged in to comment