Part 2 in a 4 part series. This post covers making solutions work. Part 1 is posted at this link.
Have you ever bought technology that doesn’t work? For instance, It could be a product or services that fails from day one. In fact, I’m not happy when technology fails.
The Manifesto for Agile Software Development authors got this right. Generally, I don’t read the manuals for most of what I buy. That is to say, if everything works out-of-the-box, then they are not needed.
Critically, we arrive at the concept of making solutions work.
The second value;
Manifesto for Agile Software Development
Better documentation will not help me understand crappy products and services. As a result, my preference is just enough written down to help me understand how the work was completed.
Reqs, Specs, Designs, Oh My
As a former project manager, I recall the days where I was chasing down artifacts. To be sure, it was a pain to get all the documents together for review, approval and sign-off. Granted, that has approach changed over time and I’m grateful for it.
There should always be documentation. And yet, it shouldn’t be 100s or 1000s of pages written to never be read again. To be sure, this is about making solutions work, not writing multi-volume epic no one will ever read.
Foundationally, most developers like to solve problems. But, they tend to be uninterested in detailing how the work got done. There isn’t anything wrong with that approach. However, there needs to be a balance between the solution and documentation.
Notwithstanding, different approaches are used so that the right information is gathered for solution support. For examples, see the short list below:
- Wikis
- How-to guides
- Quick reference guides
- Simple diagrams
- Conversation summaries
Remember, writing is a pain for some people. For others, they enjoy the art of capturing details on paper. Consequently, forcing work on someone is isn’t gifted for them will only make them miserable.
Pursue Technical Excellence
Firstly, understand that technical excellence isn’t perfection. It is about getting the work done with an eye on it being done well.
Secondly, keep quality in mind. If the work can be done with minimal waste, make the solution work.
Lastly, look for the simplest way to solve the problem. To put it another way, build it like a five-year old builds Lego.
In conclusion, pursue technical excellence while minimizing waste and complexity. This goes for the solution and the documentation.
Value 1, Value 2, Value 3, Value 4
