|
|
Re: Joel vs Bob and Kent. Different strokes for different folks.
|
Posted: Feb 20, 2009 10:26 AM
|
|
> <p>Recently you may have noticed noise about Joel Spolsky
> vs Bob Martin and Kent Beck. After reading some of the
> available online material, I came to the conclusion that
> may surprise those of you that know of my background in
> the Agile/TDD community.</p>
I don't know of your background, and I don't know what your conclusion is here, either.
I didn't notice the noise until this blog post (I check artima almost daily, stack overflow rarely and gave up on Kent Beck years ago), because most of it IS noise, and usually not worth wasting the brain cycles on. In my opinion anybody that uses the word "lawsuit" when talking about somebody expressing their opinion isn't really open to thought or discussion about their closely held belief.
I've read and corresponded with Joel a bit. I'm guessing that the words didn't "get away from him a bit", either. Joel's proven he's pretty good at marketing himself. I'll assume that the podcast wasn't scripted down to the word, but he probably had a darn goo idea what he wanted to say, has plenty of experience, isn't afraid of expressing his opinion and hasn't minced words often from what I've seen, heard and read.
And if opinions are bugs, Uncle Bob is in dire need of a de-lousing. I'm sure most of us here (me included, obviously) are, too.
> <p>Joel can say what ever he wants because his company
> ships products that folks buy and he is hiring! I have
> personally tested both FogBugz and Copilot and concluded
> that in many ways both products are leaders in their
> space. Joel has a complete formula for how to recruit
> bright folks and help them ship beautiful and quality
> software. His formula and tool chain is different from
> many Agile shops who also hire bright folks and ship on
> time. So we just have different schools of thought here.
> That's all. Or is it?</p>
> <p>Code and tool chains have a significant impact on
> software evolution and sustainability. For example, its
> much easier to find developers who can maintain
> well-factored, unit-tested Java or C# code. From what I
> can see this is not an issue for Joel. According to his
> blog, Fog Creek uses an in-house cross-platform language
> called Wasabi and I am sure its a well-reasoned decision
> that has worked well for them especially in light of their
> ownership structure and low turnover. While at Plumtree
> Software, I have been involved in the creation of a Java
> to c# translator used for that very purpose. We ran the
> project using Scrum and TDD and it has worked very well.
> Later, Plumtree was sold to BEA and eventually to Oracle
> which makes me believe that our approach of using a
> popular static language paid off well from a management
> perspective.</p>
I know many, many people that would say software may be able to evolve and be easily maintained in spite of being written in C# or Java, not because of it. Given Joel's description of Wasabi and what it is capable of, I think for his particular domain set that code is probably more maintainable than the equivalent in just about any statically typed language. Also, Scrum and TDD are independent of language and tool choice. I think maybe you are confounding the two? I certainly don't see how you can attribute the success of the translator to any one part of the project. Probably a combination of smart people and good timing had more to do with it than the methodology or tools, but that's nothing more than my completely unfounded opinion. You solved a particularly painful problem, which is no small feat, however you did it.
> <p>A note on the actual argument: I don't think that
> following SOLID principles and TDD (within reason) add
> much extra time - if any- to the overall development
> cycle. This claim has been widely supported over the
> years.</p>
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.
> <p>A note to Agilistas: for many projects to succeed you
> need qualified specialists skilled in usability,
> scalability, concurrency, DBMS tuning, etc. Being 'agile'
> does not mitigate the need for those specialists. If your
> project needs them and you lack them, you may still ship
> crap from the perspective of the user.</p>
> <p>Lastly, I do encourage developers who have not used
> SOLID or TDD to pair-program with some who has mastered
> these skills for a few hours and make up your own mind
> based on an actual apprenticeship experience.</p>
I think an actual apprenticeship takes more than a few hours. 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. 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?
> <p>The beauty of our industry is that there are many ways
> to succeed and there are many ways to account for
> value.</p>
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. I've been amazed many times that different stakeholders can take such different views to a single project. Different groups look at the same deliverable and some will proclaim it an achievement beyond compare and others will say it is a dismal failure. 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?
Generally speaking, the more I see and read about TDD, the more it seems to me that it is trying to formalize and codify what Paul Graham and others refer to as exploratory programming or bottom up programming. The difference being that most people that intuitively practice this style using dynamic languages just get something working, figure out it works, and move on. The tests are done in the top level and then thrown out. If it is important sometimes they are kept around, 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 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.
|
|
Previous Topic
