AVR Freaks

Software used to be an art or a craft like making pistols. Samuel colt sort of standardized the pistol making with interchangeable parts, but software was still an art. If you got a bunch of civil engineers and mechanical engineers in a room and told them to design and build a bridge, there were metrics. It takes 40 D size drawings to get the design done. The boss can look in the big drawer and count the vellum drawings. If there are 30 of them, the design is 75% complete. If you put a couple of programmers in a room and tell em to write a program, and come back and check on them every couple of days it sort of goes like "How that program coming?" "Almost done! Just two more edits!" and this goes on for weeks. Maybe months. So Software Engineering was invented to try and convert programming from an art to a science. But there are good and bad artists and good and bad engineers. Some more prolific and productive than others. There are sw engineering Best Practices. I hope I dont get the process embarassingly incorrect, but a project needs requirements. What it should do. Maybe a Use Case that describes what the program user sees on the screen. The customer tells the sw engineer the requirements. The sw engr converts the reqs into a proposal. What it will do. At contract award, the proposal gets converted into a spec... how its going to be done. This is the stage where tasks and modules and their interfaces are defined, and software timing and sizing of the modules is predicted, and processor choice based on software timing and sizing predictions are made. Then you need to know when it is done. When you get paid. The Acceptance Test Procedure is a matrix that can trace every reqirement to the spec. Need a debug process in there somewhere. When someone says this isn't working right, is it working as designed, and a new requirement is appearing? Or its a hw problem or a sw problem? Who determines the problem is fixed is sometimes a problem. Phew. Its complicated.

That's deep, Doc.