The Artima Developer Community
Sponsored Link

Weblogs Forum
Joel vs Bob and Kent. Different strokes for different folks.

44 replies on 3 pages. Most recent reply: Mar 8, 2009 8:38 PM by Jeff Ratcliff

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 44 replies on 3 pages [ « | 1 2 3 | » ]
Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 21, 2009 12:33 AM
Reply to this message Reply
Advertisement
> Great list. To flush out 2. a bit, the owners/users must be involved daily.

Well, it would be nice but after twenty years in the business I've yet to see it happen. In practise, I think that it's not unreasonable to expect a development team to be sufficiently au fait with the users' requirements such that they can keep going for more than a day without someone holding their hand.

> They can't flit in and out when they have time.

On the contrary, they can only "flit in" when they have time.

> The organization has to commit to letting the
> owners/users work on the project as a primary
> responsibility.

The users' primary responsibility is to do their job, not yours.

All this means that you have to have specs written and agreed, up front. You can't rely on making it up daily based on the day before's feedback, and you can't rely on the fact that the one one user that is available to you is representative of all the users.

Sebastian Kübeck

Posts: 44
Nickname: sebastiank
Registered: Sep, 2005

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 21, 2009 1:17 AM
Reply to this message Reply
> It has always been a weakness of TDD that tests are
> written to catch the bugs that you've already thought of.
> The code is then written in light of such tests. That's
> fine but by definition, the bugs that catch you out are
> the ones that you never thought of.
It's not the goal of TDD to find all the bugs. The goal is to build good design in. You have pair programming and/or code reviews as well as testers to get the difficult bugs out.

David Vydra

Posts: 60
Nickname: dvydra
Registered: Feb, 2004

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 21, 2009 8:56 AM
Reply to this message Reply
> It has always been a weakness of TDD that tests are
> written to catch the bugs that you've already thought of.
> The code is then written in light of such tests. That's
> fine but by definition, the bugs that catch you out are
> the ones that you never thought of.

Your statement makes me wonder if the switch to 'BDD' (behavior driven design is worth it)? What I mean by TDD is systematic encoding of the relationship between expected inputs and expected outputs. Most of us can't guarantee with 100% accuracy that the code as written is correct even when we have the precise mental picture of what it needs to do - so you write a test or an 'executable specification'. Unless you type very slowly or the code is difficult to test these unit tests take very little time to write and thus I consider them a worthy investment.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 21, 2009 6:34 PM
Reply to this message Reply
> You might have a look at this...
> http://www.infoq.com/news/2009/02/alignment-trap
>
> BTW: Knowing and documenting requirements is just one part
> of the story. The important part is to prioritized them
> according to their business value.

We could go back and forth about this kind of stuff all day. I have no doubt that it's good advice/information but it's outside the scope of my point. I'm really just talking about a given project, once it's decided that it will be done. I'm not trying to address whether it should be done.

Here's my favorite analogy for this concept: if I hire someone to come and dig holes in my yard, there are a number of things that I need to tell them, much of it before they arrive: how big are the holes, what shape are the holes, how many holes, how deep they will be, where they should be, etc. The requirements I usually see in software projects are the equivalent of "dig some holes."

This isn't rocket surgery, if you don't know really what you want to accomplish, you are unlikely to accomplish it.

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 22, 2009 5:40 PM
Reply to this message Reply
"Well, it would be nice but after twenty years in the
business I've yet to see it happen. In practise, I think
that it's not unreasonable to expect a development team to
be sufficiently au fait with the users' requirements such
that they can keep going for more than a day without
someone holding their hand."

A little hyperbole on my part but the point should be clear that the users have to commit. Failure to commit to the development of THEIR OWN software system is going to lead to a failure of the project.

Whether or not the developers are familiar with even what the users do for the organization is dependent on the setup of the organization.

"The users' primary responsibility is to do their job, not
yours."

Presumably the software is being developed for their own use to make them more valuable to the organization. I don't expect them to write code but they had better keep in mind that IT IS THEIR SYSTEM. Their commitment affects directly the quality of their new tool.

"All this means that you have to have specs written and
agreed, up front. You can't rely on making it up daily
based on the day before's feedback, and you can't rely on
the fact that the one one user that is available to you is
representative of all the users."

Having specs written and agreed upon up front tends to accompany a sign off scheme and a painful change process when the users inevitably remember requirements or realize the requirements they stated were ambiguously expressed in the specs.

Nowhere am I suggesting that a developer "make it up daily". My own experience is that a weekly viewing of progress by the users is sufficient. During that time, requirements are discussed and written in some form. (Formal signoffs should be avoided like a plague. It sets up an adversarial relationship from the start.) In the course of the week, a user must be available for questions. Without that commitment, the project will be a failure.

Kondwani Mkandawire

Posts: 530
Nickname: spike
Registered: Aug, 2004

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 23, 2009 2:26 AM
Reply to this message Reply
Woah!! Joel was on a Zed-Shaw type attack - of course minus Zed Shaw's humour, colorful lingo and the fact that Zed backs his statements up with snippets and conversation logs to give an outsider better perspective on points being attacked and justification.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 23, 2009 8:39 AM
Reply to this message Reply
> "All this means that you have to have specs written and
> agreed, up front. You can't rely on making it up daily
> based on the day before's feedback, and you can't rely on
> the fact that the one one user that is available to you
> is representative of all the users."
>
> Having specs written and agreed upon up front tends to
> accompany a sign off scheme and a painful change process
> when the users inevitably remember requirements or realize
> the requirements they stated were ambiguously expressed in
> the specs.

I absolutely agree. It's ridiculous build something based on specs that are known to be incorrect or incomplete. Building something known to be wrong is worse than building something without clear requirements. It would be great if people could get the specs perfect on the first go but the world just doesn't work that way. If you find you are going in the wrong direction, you should change course.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 25, 2009 1:18 AM
Reply to this message Reply
> I absolutely agree. It's ridiculous build something based
> on specs that are known to be incorrect or incomplete.
> Building something known to be wrong is worse than
> n building something without clear requirements. It would
> be great if people could get the specs perfect on the
> first go but the world just doesn't work that way. If you
> find you are going in the wrong direction, you should
> change course.

I'm pretty sure that there has never been a methodology of any kind that proposed building against incorrect specs or building something known to be wrong or advocated not updating specs in the light of new information.

I would still maintain that before you start coding a solution, you need to agree with the client what the solution is and it should be written down. If calling the resulting document a "spec" is too difficult to swallow, then so be it. You need it anyway. Complex technical solutions cannot be delivered with any degree of professionality based simply on daily (or less frequent) verbal agreements between some of the developers and some of the customers.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 25, 2009 5:54 AM
Reply to this message Reply
> I'm pretty sure that there has never been a methodology of
> any kind that proposed building against incorrect specs or
> building something known to be wrong or advocated not
> updating specs in the light of new information.

I've had a number of experiences where unusable software was delivered because the specs were wrong and the only way to get the issues fixed were with enhancements ($$$).

David Vydra

Posts: 60
Nickname: dvydra
Registered: Feb, 2004

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 25, 2009 9:43 AM
Reply to this message Reply
> Complex technical
> solutions cannot be delivered with any degree of
> professionality based simply on daily (or less frequent)
> verbal agreements between some of the developers and some
> of the customers.

I have seen projects do fine with verbal agreements and 'executable specs', i.e. functional tests. Gojko Adzic wrote a good book on this topic - Bridging the Communication Gap. http://www.acceptancetesting.info/the-book

David Vydra

Posts: 60
Nickname: dvydra
Registered: Feb, 2004

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 25, 2009 10:58 AM
Reply to this message Reply
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
> hours.

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.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 25, 2009 11:25 AM
Reply to this message Reply
>
> 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.

I haven't. Safaris take time. And where I am (Michigan) there seem to barely be companies with open doors some days, never mind ones that use SOLID and TDD in a pragmatic way. And you sound more rational than most folks I've talked with about this stuff. You're taking all the fun out of it :-)

Seriously, I totally agree with you in the end that shipping good products is what matters. That you can respect that different people get it done different ways is comforting.

Also, I wish I would see your harshest critic quote being practiced more frequently. I (sometimes to my detriment I'm told) suffer from the same personality quirk.

Personally I would love to give some form of a more agile process a shot (out of all of the ones I've read about, SCRUM sounds pretty close to how I work left to my own devices), but most of the clients I've ever had or the businesses I have worked for wouldn't want to be bothered. They don't want to be the guinea pig and most people like to know up front what they are paying for and when they are going to get it. With that mindset, Agile anything is a tough sell to a client.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 25, 2009 12:28 PM
Reply to this message Reply
> Personally I would love to give some form of a more agile
> process a shot

I think a lot of people are probably like me in that they see a lot of Agile ideas as being correct and desirable. My biggest problem with Agile is that it's a bit cult-like. You must do X, Y and Z (which are different depending on who you talk to) and there are these prophets walking around who you can't question. We have some 'consultants' who claim to be using agile processes but based on what I see they are not doing anything aside from plain old iterative development. The agile term is just a buzzword to them and they use it as a bludgeon.

I don't mean to paint people with a broad brush, but from the outside, the agile community appears to be drinking a lot of kool-aid. There's too much agreement and too little skepticism. I think maybe it's been infected with a cargo-cult mentality. Some agile advice reads a little too much like the Tao or Zen koans: "if you are thinking about Agile, you aren't being agile, clear your mind and let the Agile flow through you and guide your actions." That's a bit of an exaggeration but that's how some agile proponents come off.

Again, I think (true) Agile approaches are generally more right than wrong but these are the things turn me off about Agile.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 25, 2009 1:03 PM
Reply to this message Reply
> Again, I think (true) Agile approaches are generally more
> right than wrong but these are the things turn me off
> about Agile.

You only need one wrong thing to undo a great many right things. For me it's the lack of design up front (can I call that LODUF and be cool??) and YAGNI that drive me nuts because they are often, from what I've seen, carried to their illogical conclusion.

I've occasionally been able to look like a hero because of this, actually, so maybe I should stop complaining. I've done my share of cleaning up some pretty big messes because something would get "designed" and coded up nice and quick and the demo worked great and everybody was happy and then it was run on a dataset ten or a hundred or a thousand times bigger than the demo and the program would then fall over and cry so I got to make the thing actually work under what would be a normal load.

That and that alone is enough for me to take all things Agile with a big ol' grain of salt. I can't get fired up about a set of processes that has, in my personal experience, led to a great many bad decisions regarding product architecture and implementation. I'm sure the party line on this will be that the people doing this did something wrong and they weren't doing agile, but you wouldn't have gotten that vibe from the people doing the work.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 25, 2009 1:45 PM
Reply to this message Reply
> You only need one wrong thing to undo a great many right
> things. For me it's the lack of design up front (can I
> call that LODUF and be cool??) and YAGNI that drive me
> nuts because they are often, from what I've seen, carried
> to their illogical conclusion.

I think this is well worth watching and backs up my belief that the issues I have with Agile have more to do with the community and not the actual ideas at the core of Agile.

http://www.infoq.com/interviews/Agile-Skeptic-Keith-Braithwaite

I have experienced exactly the kind of things you mention above. In one case I suggest a minor design improvement to deal with things that we knew with were going to happen. I was attacked by the 'agile consultant' as trying to 'design a theoretically pure system' and 'predict the future'. What it really came down to was a fragile ego.

YAGNI is, IMO, an extremely misused term. It doesn't mean 'don't be prepared'. It really means that you shouldn't write code that you don't need today. What a lot of people take it to mean is: it's OK to paint yourself into a corner.

I've done some reading on these concepts and from what I can tell, they were never intended to mean what they mean to a lot of people. I'm sure you've worked with a system that was over-architected to accommodate all kinds of possibilities while not really working well (or at all) for it's actual purpose. These ideas are really about avoiding that but as you say they've been taken to their (extreme) illogical conclusion.

Flat View: This topic has 44 replies on 3 pages [ « | 1  2  3 | » ]
Topic: The Adventures of a Pythonista in Schemeland/18 Previous Topic   Next Topic Topic: The Adventures of a Pythonista in Schemeland/17

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use