Registered: Feb, 2004
Re: Joel vs Bob and Kent. Different strokes for different folks.
Posted: Feb 25, 2009 1:58 PM
Also, Scrum and TDD are
> independent of language and tool choice. I think maybe you
> are confounding the two?
You are correct. I did not write this part well at all. I was trying to show that "different strokes" applies to other decisions on the project, not just design and unit testing.
> I've seen many claims that the claim was widely supported.
> There seems to be little hard evidence one way or the
> other, though. I would be glad to see some.
This is a known problem in our industry. Formal academic experiments often do not correlate well to professional programmers at work. Personally, I am satisfied when I hear enough anecdotal evidence from professional programmers who mostly write code, not sell books. I am certain that I am a better programmer because I practice SOLID and TDD, but I am also a pragmatic programmer with business experience. I am always aware of the need to ship the product and adjust my development practices accordingly.
> I think an actual apprenticeship takes more than a few
A few hours is a start.
> I've sat with hours for people doing these sorts of
> things and it isn't how I work. Pair-programming usually
> makes me want to cry.
In this case, I am proposing pair-programming as a learning tool. I am aware that its not for everyone when writing production code.
>And how does one deem having
> "mastered" SOLID or TDD. Is there a special belt or robe a
> master wears, trials he must endure? Is there a proverbial
> pebble to take from the hand? Or do we just believe the
> marketing copy on the web site, brochure, magazine by-line
> or book acknowledgment/forward/introduction/afterword?
A great Russian poet, Alexander Pushkin, wrote: "Poet - you are your own harshest judge". This has been my motto all my life.
> To me that is actually one of the pain points of the
> industry, especially the "account for value" part. What is
> valuable to the person writing the code is of little value
> to the user of the code and sometimes what is of value to
> the developer and the user is not of any value to the
> person paying for the software.
It is unprofessional to bill clients for work of no value to them. If the software is maintainable and defect free due to the techniques used, then there is direct value to the customer. I agree with Bill Venners, that "hacking" code for a startup is a perfectly reasonable strategy. When I hack I still refactor and write unit tests. It is my conviction that I still go as fast as possible if you take into account time saved on debugging and not being able to follow/evolve your own code. This is the set of skills/techniques that I sell upfront and many potential clients do not hire me because they see no value in these techniques :)
> One need look no further than Extreme Programming's poster
> child, C3, to see this effect. You read the books and it
> was great! And yet the project and the system got shut
> down because it didn't do what it was supposed to do.
> Who's right?
I don't have verified info on C3, but who cares? There have been hundreds of projects that used some form of XP since then and many report great satisfaction with the techniques they adopted. There have been failures. I have been on such projects. I have seen religion on XP projects and I actively avoid religion on software projects.
but most of the time the tests are
> tossed when no longer necessary. My observation of the
> results of this formalization process is that you get a
> lot of people that are more interested in following the
> letter of the law and not its spirit.
If you toss out all automated tests, how do you evolve the software? How do you manage risk? Do you have customers who consciously do not want any automated tests? Should only QA be in the business of automated tests?
> If TDD and its ilk work for you, great. Use them. But to
> state as fact that it makes software better, allows it to
> be developed faster, with less bugs, doesn't have morning
> breath and whatever other claims Agile and TDD proponents
> make aren't supported by any evidence from what I've seen.
> The evidence is ambiguous at best and in some cases, like
> the link James has above, the evidence seems to favor the
> tried and true software practices that are 30+ years old,
> regardless of the "conclusions" reached by the people
> selling the methodology.
I appreciate your eloquent feedback, but I still have a feeling that you have not been on a Safari. A safari trip to a shop that actively uses SOLID and TDD in a pragmatic way. At the same time, the topic of this post is "different strokes" and we agree that many great developers choose different practices and that is fine as long as they ship good products.