I don’t know why I have to blog about this. It depresses me and reflects poorly on our entire industry. It is 2014! Don’t we know better?!?

Why God? Why?!?

Apparently not. I have found myself *several* times in the past month, having to argue against a big rewrite of many thousands of lines of code. I am amazed and appalled that anyone still thinks this way, after *so* many articles have been written for *so* many years. Two of my favorites are Joel in the year 2000, and this more recent article that references one of my favorite cartoons (thanks to Lance for introducing me to the cartoon).

One thing that is different from when Joel wrote that blog post 14 years ago is that refactoring software is so much easier now. It is now *incredibly* easy, in addition to being much safer.

I don’t want to go through the same arguments again, because so many others have done it for me. Unlike some of the people I have to convince, I am not stupid enough to think that I am the first person faced with this decision, or arrogant enough to dismiss what those hundreds of other people have said. However, I will offer one small piece of advice. Often times the refactoring can happen *while* people are designing what the rewritten version is going to look like. At that point the code will be easy to change and it will be a much simpler process to add the new features.

This blog was cross posted on the Crafting Bytes blog at Refactor vs Rewrite (again)

I just finished forming a new company called Crafting Bytes with Brad Cunningham and Ike Ellis. We wanted to start taking on bigger projects using the techniques that have made us so successful as consultants. Over time we have noticed that we do much better with the projects when we take control of the project management as well as the development rather than simply augmenting the development staff. What is different about our project management style than the project management style of other companies that we work with?

One major difference is that we don’t use scrum. In a sprint developers spend a lot of time estimating the work. Estimating can be important when the estimate is used to determine whether or not the work should take place at all. However, in most cases companies were using the estimate to inform management when the product was supposed to ship, so that they could relay that information to the customer. It would be a better idea to relay the information to the customer *after* the work has been completed. It is much more accurate that way. The other reason managers were requiring estimates was to figure out how much work should be completed this sprint. So in other words managers were requiring estimates for the sole purpose of the project management methodology they were using.

The thing is estimates take a lot of time, and they are rarely accurate. Our thought was let’s forget scrum and just go with a simple Kanban board (from the Lean school of thinking). By doing this we can save ourselves countless hours of trying to figure out how much time things are going to take, and spend more time simply doing them.

OK, so that saves a couple days every sprint, but then what is the purpose of having a project manager at all? I admit that the project managers of many companies are totally unnecessary. You know the type, they spend most of their time polling individual people “are you done yet”. They could easily be replaced by voice recognition software that recognizes the word “yes”. This isn’t really project management, it is instead project reaction. Project *management* would be managing the work of the project, prior to it starting. In short a project managers job is to figure out which work is the most important and which work is so unimportant it doesn’t need to be done at all. Great project managers remove all unnecessary tasks, that is all tasks that don’t lead to working software, and prioritize which features are the most important for the business and the user. In short they control the prioritized list.

Thinking of project management as simply controlling the list of things that need to get done and prioritizing the most important simplifies the job of the project manager and helps the team achieve minimum “time to value” – a vastly underrated metric.

This blog was cross posted on the Crafting Bytes blog at Project Management As A Prioritized List