in reply to "Bah! Scrumbug!" (Lessons from the scrap-bin)

The machine shop is an apples and oranges comparison, for the most part. Scrap code's value is only the time it took to write it, and often provides valuable insight into a particular problem, leading to a far faster path to the eventual solution than sitting on one's thumbs considering every possible design angle.

Perhaps a developer knows she has to link 2 tables together, but isn't quite sure whether she needs to use an inner join, left join, or right join to obtain the correct configuration. She could either spend time reading the definition of join types, trying to visualize how her data would fit together with each join, or she could simply write some code and test it out to see what happens.

In short, it could be much faster (= more economical) in computer development to do a trial and error approach than planning out every detail in advance.
  • Comment on Re: "Bah! Scrumbug!" (Lessons from the scrap-bin)

Replies are listed 'Best First'.
Re^2: "Bah! Scrumbug!" (Lessons from the scrap-bin)
by raybies (Chaplain) on Dec 16, 2010 at 14:04 UTC

    Maybe this is a natural (good) evolutionary process, but ever noticed how those that spend huge amounts of time upfront overdocumenting their designs, tracking effort, and writing long specifications for interfaces end up in management--and lose their ability to code fairly quickly?

    Maybe that's just part of another trade-off? Programming competence requires programming--all the time. Filling out Design change requests and forms for peer review will probably get you somewhere too...

    (Of course that's an egocentric view, unrelated to a customer who couldn't care less as long as he gets what he wants...)

[reply]
Re^2: "Bah! Scrumbug!" (Lessons from the scrap-bin)
by locked_user sundialsvc4 (Abbot) on Dec 16, 2010 at 14:42 UTC

    I’ll once again very politely dissent ... and yeah, I won’t bother to keep doing so.   The perception that is obviously encouraged by many folks, among many other folks who ought to know better, is that ... if scrap code is not “free,” at least it is “cheap.”   It is neither.

    Just let the record show that I only want to hire the programmer who damm well knows what kind of join to use, and who does not have to “try them out first.”   She is the one who I want to be working on a production dataset that I am right now looking at, which has 338,207,496 rows in it.   I am not running a school here.   I am here to try to figure out why another client’s project is crashing and burning, and, once again, I think I know.

    I almost never find incompetence.   I usually find neatly indented code and I usually find comments!   What I always find is a process problem.   The team knows how to do it.   But, the team does not know what to do.   How can you “cross that bridge when we get there,” if there is no assurance that the bridge will exist, much less be capable of supporting the load (which is also “to be determined”)...   Fifteen years ago, I thought what I was seeing was an anomaly.   But I see it to this day.

    If there is any central theme to what I am saying, it is that our industry has a reputation for “trial and error,” “fly by the seat of our pants (and we’re proud of it ’cuz what we’re doing is so magical and wunnerful that it has to be this way)” practices.   The sooner we can get rid of these notions and start doing what every other engineer or homebuilder has been doing for generations, the better off we’ll all be.   “Flyin’ away on a wing and a prayer” belongs as the theme-song of Greatest American Hero, but nowhere else.   This thing that we are all doing is not so gosh-darned remarkable; at least, not anymore.


    (“Okay, I’m done,” he says. Quietly steps off the podium, picks it up, puts it away.)

      That sounds more like a unclear or misunderstood requirements issue to me. But I may be missing your point.

      I have worked too many projects where the ongoing answers from client and management were I am not sure what I want .. but that's not it Individual developers should never have to deal with requirements which leave them unlcear what they are supposed to do. And they should have some process to allow them to push back if they find themselves in such a situation

      On the other hand a lot of the code I have written has been at least to me and the teams I worked with, relatively new territory with very little available prior art to build on ... not much you can do there but trial and error somtimes. Or cases where the delivered specs for somthing you had to interface with were just flat wrong in one or many critical points.

      This may explain why I am a firm beleiver in an interative development process 8^)

      Misha/Michael - Russian student, grognard, bemused observer of humanity and self professed programmer with delusions of relevance
[reply]
      I only want to hire the programmer who ... knows what kind of join to use, and who does not have to “try them out first.”

      Riddle me this: what's faster, bubble sort or quicksort?

      Nota bene that I have not explained the characteristics of the data set.

[reply]
      I must say that you are very fortunate to have talented developers, but that is not always the case. Luckily I am in a position now where I am a one-man army (has it's ups and downs, for sure, but at least I'm solely responsible for f-ups). In the past I was with a company where there was one person for each phase of SDLC. I lost count of the number of times where the Design document and/or Programming Specifications were completely useless documents written by someone who only had an ephemeral view of the intricacies of programming, and ended up being worthless, and a waste of time. Time that could have been put to better use.
[reply]

In Section Meditations