Steve McConnell has spent most of his career focused on educating software professionals. He’s written many critically acclaimed books, including: Code Complete, 1st and 2nd editions Rapid Development Software Project Survival Guide Professional Software Development Software Estimation: Demystifying the Black Art I’ve recently reviewed Code Complete 2nd edition myself, and am currently reading Rapid Development.…
I attended Banking on Agile feeling pretty jaded about Agile. However I learned that there is still a huge amount of passion and excitement about Agile. In most small companies, Agile is the obvious approach in most circumstances. In the Banking industry, each company is so large that Agile could never win over the old…
At the time of writing (last updated 3rd June 2015), the beta of the No Estimates book is still available for free on the condition that you provide feedback on it. The final edition may end up significantly different to the version currently available. So instead of reviewing the book from a “should I buy?”…
It is easy to find a lot of advice online about Agile development, but unfortunately this also means it is easy to find a lot of bad advice online. For example we have this advice on changing your sprint length: http://futureofcio.blogspot.co.uk/2014/01/ideal-agile-scrum-sprint-length.html It is important to be a bit sceptical about any advice you read online…
Originally posted on Home of the Mikado Method:
For quite some time now we (Daniel and Ola) have been working on a book together. As you may have guessed it’s about the Mikado Method. Some of you are already familiar with our work through workshops, this blog or maybe the early version of a PDF…
Recently I have been reading Code Complete by Stephen McConnell. It is a very big book with over 900 pages and a ton of useful information. Many IT organisations could do a lot worse than to base significant parts of their strategy around this book. However there is one paragraph in the “Handling Requirements Changes…
Part 2 of the debate is much more interesting than Part 1 for those of you interested in software architecture. It covers the concept of “Test Induced Design Damage” and discusses whether TDD leads you towards good designs or to bad designs. This post summarises the conversation for those of you without time to watch…
Introduction My name is Mike Dexter and I have over 14 years of experience in configuration management and 10 plus years in change management accompanied with several years of process in waterfall and agile. If you would like to know more about me I can be contacted through the following sites: http://mdexterscms.wordpress.com/ https://twitter.com/MDexterSCMS http://www.linkedin.com/in/mikedexter …
In my guest post on Mike Dexter’s blog, I briefly touch on estimating in hours. Estimating in hours during sprint planning is something that’s been around for a long time. Robert Martin notes this in his popular and influential book Agile Principles, Patterns, and Practice’s: Many developers find it helpful to use “perfect programming hours”…
I am writing this post to correct a mistake I made. I had this twitter conversation with Jeremy Kahn: When faced with these deadlines, developers often take whatever shortcuts they can find to meet the deadline, and the code suffers as a result. Although it is certainly true that this is a major cause of…
Zombie Code Kill 