The main concern (I have a similar problem with my job) is that if "The Process" demands that you deliver certain artifacts at certain times, and no one is allowed to challenge the almighty "The Process", then if you try, you will loose! It's not just a simple matter of it being a better way (Which iterative doc development is).
So what you need to do is work within the process, but find a way to work the way you want to as well. For instance, does your process allow document modification once submitted? If not, then no iterative develpment is possible. If so, then you need to think about the cost of delivery (In terms of your time, your credibilty etc), and manage that cost. If, for instance, its a file copy and nothing more, then go for it. If (like me) it's a peer review, revision release, impacts dozens of people and costs thousands of dollars, then think carefully and make sure the new document really adds value.
A common way to work is a bare essentials, minimum document that meets the needs of "The Process" at the start, followed later by a final "as built" update that not only reflects reality, but has the details where needed, and is brief where the code speaks for itself.
You sound like a Software Engineer.
A Project Manager is more focused on the status of the overall project and allocating resources in an effective way to ensure that milestones are being met and in proper time. They also remove roadblocks and help the project resources focus on their specific job functions.
Writing and maintaining design and technical documentation is an important part of being a software engineer and is appropriate for your role. Too much of a good thing can be bad though (See Analysis Paraylsis ).
He considers the design to be paramount, coding is "just writing the design down"
If the project manager considers the design documents to be paramount then he expects the documents as a deliverable in the process. It is not a wasted time on your part if he feels they are important enough to allocate 80% of your time to it.
it shouldn't take too long, and "all the code should be written before the hardware is ready".
This is wishful thinking and quite an antiquated Waterfall style view of how software development works. It invariably is never that clean no matter how much design and preparation that you devote. On that note however, you should have clear hardware specs and proper test environments and mock hardware simulations for your code to interact with but again, the real world is messy.
Project management is incredibly easy in a perfect world. The world is not perfect however no matter how much you wish it to be so making real project management incredibly difficult. This is why they are paid the big bucks.
(2) Doesn't understand the difference between a Central & Distributed Version control.
Why should he care? How does it affect the milestones? It doesn't.
3) Doesn't understand code, and wants to understand every bug and its proposed solution
His goal is for working software and yours should be too. He does not need to understand the code but he does need to understand the issues that are preventing working software. Once the two of you see eye to eye on this basic level then your mutual goal will help you work together more effectively.
(4) Believes verification should be done by developer, and validation by the Tester.
What is wrong with this sentiment? Testers in the quality assurance role should be concerned with validating features and requirements. Developers should make every effort to verify and test their work before it goes to testing.
I don't really like creating documents, I want to solve problems and write code.
If you would rather be a simple programmer then perhaps you should talk to your boss about this and see if there is a better role for you on the project. Somebody needs to write and maintain the technical documentation, so perhaps one of the other developers can help you with some of these tasks so you aren't spending 80% of your time writing documentation.
In my experience, creating design documents only helps to an extent, its never the solution to better or faster code.
This is mostly true... but only if all ten developers are spending 80% of their time writing technical documentation that nobody will ever read. This is an enormous management anti-pattern that I have lived in before. If you find that you are doing most of the documentation for the team then it hardly seems fair that you are denied the right to perform more coding work.
The fact of the matter is that the best technical documentation is the code itself.
I feel the boss doesn't really care about making better products, but only about being a good manager in the eyes of the management
I feel that he does care because the product is his ward and if projects and features are not completed and clients aren't happy then upper management will not care for him very much. The problem is that your perspective on the necessary quality improvements don't match with his, and upper management, and the clients perception of what they feel is important.
Try to understand what is truly important for the product, because while you can increase the efficiency of a process 3 fold, if you spend an entire week doing this then it is at the cost of another important feature that the client is demanding.
We all want to look good to the eyes of our superior. There is nothing wrong with that, it is human nature to be self serving. This is a fact of life.
Best Answer
The author of the blog post was trying to make a point about how the Agile Manifesto emphasizes "working software over comprehensive documentation", and that when you do this, you risk losing the information about how software is supposed to work.
What's needed, whether it's Waterfall, Rational Rose, Agile, or some other SDLCM, is a "statement of purpose". It is some textual description of what is to be done, and why, at a detail level fine enough in the right areas that a developer can take this description into the team room as his "requirements", and produce correctly-behaving software as a result of his development efforts, guided by whatever methodology he or his team or managers see fit to follow.
In Waterfall, this is the Requirements Document. It's all defined, in detail, up front, before development begins, and if it changes while the project is out for development, development stops and the team reverts to the "design" phase.
In UML/Rational Rose, this is a "use case narrative". It describes what the "actor" (a person in a specific business role, or an external automaton such as another program) will do that should trigger some action, and what will happen within the system as a result of this action.
In Agile, this is a "user story", the exact form of which can differ depending on the exact flavor of Agile, but the two I've seen are similar to a UML "use case narrative" and a slightly different approach: "As a... I want... so that...". Similar to a use case in that the actor and the basic action are mentioned, but the addition is an integration of the business need into the context of the story, so when designing the solution, the development team can keep the business need in mind.
None of these is a "readme", and frankly I wouldn't want to read a readme that was written in the way the blogger suggests; it will be long, it will be ordered only according to the order in which the developer added the requested features, and it will be written by a developer, who will have his own perspective on what he's adding or changing and why that may not coincide with the perspective a user would have.