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

The design of the part and the engineering of the process to produce the part were probably not the product of the machinist producing the part. Think of the machinist, no offense to machinists here, as the compiler. The mill, lathe, drill press, welder, and other machines he runs you can think of as libraries.

The software design and development process is fundamentally more like the design of the part and the process engineering for how to produce the part than the actual production of the part. The engineers select the metal, draw the plans, determine the steps of the machining process, and minimize the cut-away (also referred to as "scrap", but very different from scrapped product).

When there is a scrap product from a solid process, it's because there was a mistake made in the machining process or a defect in the raw material. Neither of these is the direct fault of the design engineer or the process engineer. Those scrapped parts may be blamed on the machines, the machinists, the machine maintenance crew, the materials buyer, or something else.

When there's a bug in the process, that's when you blame the process engineer. When there's a bug in the part design, that's when you blame the design engineer. Maybe some independent CAD drafter or CAM translation crew who cut corners in assisting the design engineer could be blamed. Most DE's do their own CAD drawing and CAM translations these days from what I understand. Some CAM and CNC software actually reads straight AutoCAD or Microstation files these days, too.

One of the biggest problems I see with software is the lack of a design engineer in the first place. We have plenty of tools and toolmakers to help us implement. We have plenty of advice on process. What is usually lacking is proper design.

You can't develop a process and implement a completely serviceable product without developing a solid idea of what the process is supposed to produce. This is where solid customer stories come in for custom software or software as a service. It's where good market and user research comes in for software as a product. In either case, a UI designer or usability expert can probably help. Someone skilled in writing in the problem domain probably can, too. I've actually found it helpful to have one or a few typical end-users assigned to connect with the development team to answer questions and try out every iteration of the software. It works much better for quality control than throwing code over the wall and taking back reports from "the customer" as a black-box entity.

Maybe you can find a good internal or external customer to pay for your software to be developed for them and allow you to sell the finished piece as a product. In that case you can do agile development using customer stories even for a shrink-wrapped product. Your customer's needs are probably not unique after all. If nothing proprietary is tied up in the code they might take a discount on the up-front work in exchange for letting you keep copyright and resell the work. Most of the agile processes work best when you already have a customer with a defined need, after all.

  • 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 MishaMoose (Scribe) on Dec 16, 2010 at 13:32 UTC

    Overall a great discussion, thank you all. The well developed discussion of the differences of opinion reminds me of many battles I have been forced into over concepts such as Software Engineering, Development Methodologies, Management Quality Initiatives, ad nasuem. When you get right down to it the process of creating functional software is still more art than science or even engineering as it is understood now. Creating software is really more akin to the development of a commissioned art work than designing a new electrical circuit.

    Why? Well I suspect that centuries or at least many decades of prior ‘art’ in the other ‘engineering’ disciplines has a lot to do with it. Software development is till something that is only about 2 generations old. Many of us here started our careers in the very early years of our art. We grow closer each year to becoming a true engineering discipline. But the progress is slow

    I remember mangers who 15 years ago insisted that network services should be as robust as telephone networks. They forgot that telephony had had over 100 years to build that robustness.

    Too many mangers still insist that methodologies that work in other industries and processes are perfect fits to software development. Six Sigma worked wonders for Fed-Ex and the Army Logistics command and ….. etc. so therefore it must be perfect to apply to the process of software development. Um not so much.

    It I so easy to be drawn into the cult of measurement that we forget that we have no idea what we are trying to measure or what the numbers we come up with actually mean (if anything) … remember source code line counting?

    We need quality processes to improve our products but I think that until we develop these things from with our own ranks we are not going to move forward very successfully.

    We all have suffered managers who do not understand what we do, how we do it or anything about the process. I personally think that managers who are responsible for managing developers and other software folks should have been software people at some point. The numbers of us who become managers is growing but the percentage is still pretty low. .

    As always these are my 2 kopeks worth. YMMV and probably will 8^). I do hope it will stimulate more such excellent discussion.

    Misha/Michael - Russian student, grognard, bemused observer of humanity and self professed programmer with delusions of relevance
[reply]

      If you have never read the book, Cheaper By The Dozen, I would recommend it to you all.   This book was written by the daughter of one of the original management-practices gurus:   the people who counted the number of movements made by a person’s hands, to try to reduce wasted motion.   The kind of person who weighed a tube of toothpaste.   So, absurdity masquerading as science is not altogther new.

      It is strange to have been on both sides of that manager’s desk, and I certainly know which side of it I prefer.   In the manager-seat, you are responsible for the outcome but you feel that you have no real control over it.   But then, when you turn away from The Dark Side   ;-) ... you find that you just can’t stomach the various “methodologies” any more.   You realize that they consist (IMHO... just IMHO...) of excuses for an utter lack of process, masquerading as process!

      Yes, we can determine how long a project is going to take to complete.   We can bring the ship into the dock without the slightest bumping into it.   We can finish a plumbing job and turn the water on and not need to have a bucket and a wad of towels in our hands, “just in case.”

        I have read the book and seen the B&W version of the movie many times. It is one of my favorites.

        One part Iliked alot was when her dad observed that while saving with a razor in each had should was faster ... he lost all the time he gained fixing all the nicks

        I agree that we can do all those things, every time, ... when we have the the tools and leadership and the understanding. But in a lot of areas we just aren't IMO quite there yet.

        Misha/Michael - Russian student, grognard, bemused observer of humanity and self professed programmer with delusions of relevance
[reply]

In Section Meditations