Just finished reading this book. Published in 1996 (16 years ago), the advice and lessons provided is still very relevant. Even if in your job you don’t have the mandate to solve any project management issues that exist, it’s a very helpful read to help understand why things might be the way they are.
I recently discovered the blog of Jens Schauder thanks to a colleague, and wanted to note links to some of the posts I found interesting.
Boolean Stack – an idea of simplifying complex boolean rules by expressing them instead via collections of “allowing rules” and “denying rules”.
Developing for Supportability – exactly what it says, including how important it is to make it easy to stop and start your application.
8 Reasons why the Estimates are too low – the top 2 of those I have experienced are: having estimates prepared by developers familiar with the area of the system, and then expecting completely new developers to take the same amount of time; and estimates having to be made with nowhere near enough information available.
Another extra one I have seen is the assumption that all developers will spend 80-100% of their time on their tasks, which doesn’t allow enough time for meetings, design and code review sessions, etc. Starting at 80% would be fine if there was some effort to monitor whether this was realistic and then adjust it if necessary.
One Database for Every Developer – enough said. It’s not as bad if your application only reads from the database, but it’s still a pain at times.
About Packages – how packages aren’t always used effectively. As mentioned in the comments, I also see packages too often used as sorting containers e.g. “exceptions”. I think if we paid more attention to this, we’d also put more thought into the visibility modifier of our classes instead of just making them all public.
Breaking Dependency Cycles – what it says it is.
Fixing the Singleton – why singletons should only be used via dependency injection.
I’ve come across an interesting article at Thomsett International about estimation games in software development.
I’m fortunately lucky enough not to have been subject to such unhelpful things, but I do believe that it’s important to take time and care to come up with proper estimates that have value. Caveated “finger in the air rough guesstimates” can be dangerous in the wrong hands.