Category Archives : Development

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?


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).

So You Want To Write Your Own CSV code?

So you want to write your own CSV code?

So You Want To Write Your Own CSV code? Fields separated by commas and rows separated by newline. Easy right? You can write the code yourself in just a few lines.


Hold on a second…

Ryan Seifert‘s insight:

This is a great short article on how a ‘simple’ feature or request can balloon into a much more difficult and time consuming issue.

While the author jumps into some areas that are more than likely not going to be used; it is hard for the developer to know all edge cases. Substantial segments of work can potentially be removed if we know the originating file is RFC-4180 compatible or detailed information on areas it is not. Fully fleshed out requirements could answer those questions; but usually not before an estimate is requested/required.

Four Million to One

Four Million to One

We Help the World’s Best Developers Make Better Software.


As we pass four million Trello members I thought it would be a good time to share with other small software development teams the fact that providing high quality support doesn’t have to be expensive or impossible.  This includes a one business day initial response window for all newly created cases and making sure to follow through on all open cases until resolution.  With just a few tools and some dedicated time, it is possible for even just one person like myself to support our entire member base

Ryan Seifert‘s insight:

This is really inspiring!


I love the thought put into the support system. Many times support takes on the role of firefighter; reacting to extinguish flare ups and hopping from one fire to the next. The critical points I spot are the extensive online help (with Analytics even!), the canned email responses, and the smooth ability to escalate support issues. It is exciting to see how a single person can support over four million users!

See on

XP Users Permanently Vulnerable to New Internet Explorer Exploit

XP Users Permanenty Vulnerable to New Internet Explorer Exploit

An alarming new vulnerability in Internet Explorer lets cybercrooks bypass essential protections and run malicious code on your computer. Naturally Microsoft will issue a patch, but if you’re still running XP, you won’t get it.



Ryan Seifert‘s insight:

I think we all know at least a couple people who are still on Windows XP. Earlier in April Microsoft dropped support for Windows XP (No April Fools!); and unfortunately shortly thereafter a remote code execution bug was found in Internet Explorer. If upgrading to a new OS is out of the question, browser alternatives such as Firefox and Chrome are not vulnerable to the exploit.

See on