Remember structured programming?  The "right" way to design software is to start at the top and decompose into a hierarchy of subroutines until you get down to the routine that does not have to be decomposed.  But the modern Object Oriented programming is not hierarchal.  And when you are working with unknown devices, you have to stat from the bottom.

Remember  ISO 9000?  The right way to run an organization is to spend 6 months and document every process and put them in a big book by every door.  But then you have to rewrite every book, if you change anything.  Do you know where your ISO 9000 book is now?  It is probably shredded in a landfill somewhere.  

Do you remember quality circles?  It seemed to be good for Japanese auto manufactures, but it was quickly dropped in American engineering organizations.  All that talk did not get anything done.

A lot of good ideas don't actually work.  A lot of popular authors did not test their ideas for 5 years before publishing them. A lot of good ideas that actually work are eventually replaced by ideas that work better.   You should always collect the best ideas you can find and them be prepared to replace them with better ideas later.  You will not know if an idea is really better until you try it, and if it isn't better, you may have to go back to the old way.  Always be looking for better ideas from people your trust.

(To be serious, the things you know might have been the best ideas once, but there are better ideas now, so the old ideas are now "wrong".)

Separate Development from Testing:  The original idea was that testers had to be objective, and they would lose that, if they were too close to the developers. The idea sounds good, but if you compare projects who isolate testers from those who integrate them, you find that integrating works better.  Testers in isolation are always the last to learn about changes to the system.  Testers in isolation do not get influence into the design to make it more testable.  Testers isolation do not get help from the developers in automating the test process.

Testers need  a frozen spec to get started:  The spec is not frozen until the project is over.  If you wait until the project is over, it is too late to make changes, so testing is useless.  If you wait until the spec is mostly frozen and then start developing tests, the test process will take so long, that management will push the product out the door before testing is done.  The longer you wait to test the more expensive testing is.  So, how long should you wait before you start designing tests?  Find some data and connect the dots, man!   The longer you wait to test the more expensive testing is, so don't wait.  Start designing the tests before the software is designed.  Yes! It really works. The tests follow the evolving specifications, and the design follows the tests.  That lets you run the tests as soon as any software is written, and the waiting time can be measured in seconds.  The bugs come out almost before they go in.

You have to legally bind the customer to stop them from making changes:  Why do customers keep making changes to what they asked for?  Because they are starting to learn what they really need.  The idea that any organization can take a week or a month or even a year and write a perfect statement of their needs is pure fiction.  It rarely happens in real life.  You can demand that they accept what they originally asked for, even though they now know that it is wrong, but they will be unhappy.  Next time they will get someone else to help then, and that is not in your long-term best interest.  All this "Agile" stuff is all about how to run a productive project while people figure out the real problem and a workable solution.   It is real, it is necessary, and it is here to stay.

The design documents evolve into maintenance documents: Constantly updating all the design documents every time there is a change in the design is a lot of work. So, why do we do it?  Because we all know that it is important to have maintenance documents to capture the knowledge that will soon be slipping away.   But when you look at a really good maintenance document, it looks nothing like any design document you have ever seen.  Good maintenance documents are glue that organizes the code, files and directories that make up the code.  It builds on top of the documentation in the code itself.    You really can't write one of these until you know the code.   You can have a bad maintenance document if you rewrite the design documents over and over again though out the project, or you could spend a fraction of that effort writing a good maintenance document at the end of the project.  It takes a little discipline to save some resources for it, but it is much cheaper than doing it the other way.