Documentation is one of the things that everyone wants, but no one provides themselves. Nearly every organization suffers this. "Read the code" is not a good answer when time is a factor. I write obnoxious amounts of documentation as I write systems. I used to get called out for it, until I would be out, a problem would occur, and then someone else was easily able to take care of it by reading said documentation.

The main time waster for me is being told to "maintain" a system instead of refactoring it. A great example is a recent project I've finished up. Years were spent trying to create bandaids for major design deficiencies. They never solved the problem since there were fundamental design flaws. It was slow. It produced only somewhat useful results. It required lots of time and effort for maintenance.

After much hemming and hawing (and the reality that the system hadn't delivered its expected value after 3 years) I was given the green light to rewrite it. I spent a month validating the design, and 2 1/2 months rewriting it and putting it into production alongside the existing parallel system. The new old system will be turned off in 2 or 3 weeks.

Benefits?

* It produces correct results for downstream apps. This item alone made the effort worthwhile. Everything else is simply gravy.

* As a result of the first item, we now have reverse engineered another vendor's feed with uncanny accurcy. We can now "front-run" them, reducing our latency to act in the market. We can also cancel a subscription that has a $200,000/yr price tag. We can also decommission that system freeing up hardware.

* The time is takes to load new data from the vendor was reduced from 50 minutes to 4. It now scales perfectly linear with new data volume, instead of ever-increasing over time. It can also still be faster (down to ~3 minutes), but those improvements need to be made by another group.

* Since its faster, and has very little overhead, the server has gone from burdened to idle. We can now have other systems take advantage of this great hardware (16-core, 64GB of memory, FusionIO scratch space, very fast SAN hardware).

* The storage footprint of the data warehouse was reduced by 50%.

* On top of the storage reduction, replication to our disaster recovery site was reduced by an additional 70% (on top of the initial 50% from reduced data volume) because of how the data is structured.

* Source code reduction? 85% fewer lines. It is now ruthlessly simple.

* Maintenance? It now auto-recovers. Untrained operations staff just perform 2 automated steps to recover from 99% of problems that we expect to occur in production.