Monthly Archives: June 2014


Defense Against the Dark Art of Estimation Bargaining

Defense Against the Dark Art of Estimation Bargaining

Let me set the scene for you. Someone strolls up to you. It could be a manager, a customer, or even another developer. Let’s just call him Peter:

PeterHow long would it take to replace our billing system?YouIt’s pretty complicated, maybe a 8 weeks?PeterWe need it by the end of July.YouBut that’s in 2 weeks!PeterThis is really important, when is the soonest you can you get it done?YouWell we can shoot for 4 weeks.

How did you suddenly agree to do a 8 weeks work in 4 weeks?

Source: monkeyandcrow.com

This article hits close to home; I find myself in this situation almost daily. Personally, the most important take away is pushing the estimate until a complete scope of the project is provided. When I provided the estimate from the quick description of the scope included was a disclaimer on requiring the option to update the estimate later. In my experience, executing that disclaimer to update the estimate comes too late to change the schedule; you are then left to attempt to remove features or schedule overtime (paid or otherwise).

How do others handle these situations? Blocking until the full scope is provided is not always an option; at which point do you take a shot?


How To Spot The Legacy Code Writer

How to Spot the Legacy Code Writer

In Working Effectively with Legacy Code Michael Feathers defines Legacy Code as “Code with no tests“, which reflects the perspective of legacy code being difficult to work with. I’ll stick to this definition.

 

Ryan Seifert‘s insight:

This is a great article on how code evolves in an organization. A quick fix here; a small misstep there can easily accumulate to a difficult to maintain piece of software. Even if the initial code is wonderful; new techniques and unexpected features can cause the code to evolve into unexpected, and unwanted, ways.

While I agree on the conclusion of the article, attempt to leave the code a better place than you found it, there are certainly difficulties in doing so. I know that in my experience you will not always have the availability to refactor the system; sometimes you will have to leave it at the current status quo. What I have found that works is to start to keep track of the more problematic areas and keep estimates on how long a refactor for those areas will take. The next new feature or update to that area, you can include the refactor time (be sure to flag it as non-billable if necessary) and simply perform it during that project. The refactor is included in the schedule (along with the enhancement) and should not cause any unexpected delays (which a surprise refactor could).


FCC Comment Page Buckles To Its Knees After John Oliver Asks Everyone To Comment

FCC Comment Page Buckles to Its Knees After John Oliver Asks Everyone to Comment

On Monday morning, we wrote about John Oliver’s brilliant report on net neutrality, which ended with a stirring “call to action” for internet commenters to tell the FCC why it should preserve a free and open internet. If you somehow…

Ryan Seifert‘s insight:

I can’t say I have ever watched the show before now; but I am a fan now. The segment really did wonders on explaining the issue and providing some much needed background on the problem now. Even better are the results; with the outcry crashing their page (and locking their phone lines).

If you haven’t voiced your opinion to the FCC on this; please do. Keeping net neutrality is very important to ensuring new companies and technology stay stateside.