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.
In reply to Re: "Bah! Scrumbug!" (Lessons from the scrap-bin)
by mr_mischief
in thread "Bah! Scrumbug!" (Lessons from the scrap-bin)
by locked_user sundialsvc4
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |