As I do almost every day, I was reading my favorite development blog on Tuesday. He had a link that was simply titled Agile Software Is a Cop-Out. That definitely piqued my interest. It had a captivating title, and dealt with a subject that has mixed feelings (even for me internally) – project management and software development.
I think the author makes some good points, which I’ll get to in a few minutes. But first, the thing that bugged me about the post. The thing that bugged me about his blog post was that he thought that the measure of progress being working software was too narcissistic. Under this point he states
Software is always part of a bigger picture. It works in conjunction directly or indirectly with other software, technologies, the environment, business processes, and people to create customer experience and/or improve operational efficiency.
As I read this I thought “Yes. It does. But how is that relevant here?” What I mean is, that software absolutely is always part of a bigger picture, but seeing as it’s part of a bigger picture means that in order for it to work, it must work in that bigger picture.
Let’s take care engines, as an example. A car engine is composed of several systems (more than I realize, I’m sure.) Can we measure progress by the fact that fuel is injecting? Yes. Can we see progress when a spark plug ignites the injected fuel? Again, yet. Can we say that the engine is complete when those 2 things happen? No. But it’s a measure of progress.
That’s all that we need to do with software. Are we making progress? The best way to know is if there is deliverable functionality (even if that functionality is a login that just redirects to a home page.) Notice that the agile manifesto says nothing about what is “working software” That’s up to the users to decide. In effect, what I like about the developer-centric nature of the agile manifesto is that it doesn’t dictate when something is working or not. That is still up for the users to decide. It puts the onus on the developer to figure out what needs to be done. The developer can’t just say “It compiles without errors, it must be done.”
All that said, I think that Mr. Gualtieri had some really good points. One of his best points was to call developers to be professional. He says it a little different, his exact words were “Great developers must be design and domain experts.”
That’s something that has bugged me for a long time, is the mentality that I’ve seen several developers exhibit, that they don’t need to know anything about the domain, they’re just there to write the code. For at least the past 4.5 years, I’ve told each of my bosses, that if they’re paying me to write code, they’re getting ripped off. What I’ve meant is, I have good analytic skills, I desire to understand the problems I’m working on, I want to find better solutions. How can I do that if all I do is write the functions that are spec’d out in front of me? The answer is, I can’t.
I liken it to building a house. The general contractor has an excellent understanding of what look the homeowner is after. He knows which windows they’ll pick, the cabinets, which rooms have hardwood, which have carpet etc. He’ll know if the facade is aluminum siding, brick, wood etc. Yet the guy that’s framing the walls doesn’t know any of that. All he really knows is that this wall needs to go right here. Guys that don’t understand a significant portion of the domain are like the framer. They can build some great walls, but at the end of the day, they didn’t build a house.