Shoveling Snow and Fixing Bugs

Dec 27

Shoveling snow is best done early, you may have to do it again, but it is a far easier affair. The same is true of buggy or troublesome code in a project, the sooner you fix the code the easier it will be.

The longer you wait to shovel the worse it gets, besides the additional snow you have to move. The snow may get compacted, or freeze into ice.  So you will end up breaking ice, salting, besides shoveling. The same is true when maintaining a project, and you wait to fix a troublesome section of code. The problems will start to pile up and dependency may be built on top of the code. Then when you actually get to fixing it you have to fix not only the initial problem, but any dependent code.

Sometimes our hands as developers are tied, the budget maybe tight, but we should understand the business case for fixing something earlier, and try to estimate the cost of not fixing it if there is resistance. That being said we should also be cognizant of balance between our need as programmers for quality, and the bare minimum which will provide our customers, internal or external, the value they expect.

“Fix early, fix often” is my philosophy for dealing with bugs. When you delay fixing a problematic section of code, you will pay for it with  interest.  Having a clean code base is even more satisfying then having driveway and walkway clear of snow.

By admin | Posted in QA | Tagged , | Comments (0)

Pass Time “Estimating a Feature”

Dec 24

So as I am channel surfing, and I come across the show Pass Time. I watched two episodes straight through last night. For those of you who have never seen it, the show is a drag race crossed with a game show. Three contestants must guess the pass time of a hot rod in the quarter mile. If they are the closest they win. The process they go through is exactly the same process we as developers go through when estimating a feature.

The process of the show is fairly straightforward. First the driver may introduce their car, and the contestants may ask them three questions.  Usually something about estimated horse power, if the car has nitrous, or other types of modifications or parts. The contestants make their guesses, and the driver runs down the track, and the person who is the closest gets $100. Repeat until the end of the show, whoever has the most wins. The video below explains it.

To tie this back into software development, and how this is like estimating a feature request. Usually when some one requests a feature, you as the software developer has to come up with an estimate on how long it will take. The requester or an intermediary will come to you and explain the feature, you will have to ask them questions, these questions will help you figure out the basic details about the request.

You like the contestants you must rely on your knowledge and experience to put up a guess on how long it will take.  It is an educated guess. Maybe there will be a driver or mechanical error which could drastically alter actual time. The same is true implementing any feature, maybe their will be programmer error, or an unforeseen complication with the underlying system. Our best estimates will not usually take this into account.

Some people are better at estimation, but a lot of estimation is experience. Usually the first question or thought you have is: “Have you seen something like this, or at least something with similar components.” The more projects you work on, the more you can observe and learn about what slows down or speeds up a project, and use this as a base for estimates. Most quick estimates we make a calculation of a positive and negative factors on some base which is familiar. This is exactly what the contestants are doing.

By admin | Posted in Uncategorized | Tagged , , | Comments (0)

Don’t Repeat Anyone’s Work (DRAW)

Nov 20

Draw

As programmers we forget the fact that many of the problems we encounter every day have already been solved. We don’t need to write a sort algorithm, create a new type of data structure, or write an encryption library from scratch.  We try not to repeat ourselves, but we have no problem repeating every one else.

I know that programmers love acronyms, play on words, and guidelines. Therefore, I am proposing the DRAW principal. Don’t Repeat Anyone’s Work.

This is defined as: Not solving generic and common problems that have already been solved. This may take many forms, it could be as simple as using a common library, or it may be more in depth such as reading the code of an open source application, or even looking up a general form of an algorithm.

This is a problem that many programmers have faced for a long time, and we have complained about it for a long time here, here, and here. Sometimes we think we can solve a problem very quickly, sometimes we don’t know some one has already solved it, we may even think we can do a better job, or just maybe we are doing it for hack value. Whatever the reason we have all, took the time to solve a problem that has been solved before, that could have been handled with a quick Google search.

Many times Google will return an answer you are looking for. Last week I had to parse a comma delimited list, passed as a string from from a web service I was integrating into a .NET application. Below is the Google search I used, which return a number of results. Parsing CSV data is something that has been solved thousands of times before. It was that straightforward.

parsecsv

Part of being a good software developer is knowing when to be lazy, and find an already existing solution and when you have to hand code something. The basics of this principal is being knowledgeable about the language you are using, and being able to research problems, and leverage the resources of the developer community at large.

Footnote this is play on the DRY Principle
By admin | Posted in Uncategorized | Tagged , , , , | Comments (0)
Profile Picture

About Ian Lintner


I am a software developer, mostly web,  in Des Moines, Iowa. I take a very opinionated stand concerning development, you will never regret a simple design or architecture. My education was at Drake University in Biology and Computer Science. Offline I am recently married to my wife Heather. I try my hand at many hobbies currently I am gardening till the snow comes in.



My Current Projects


Des Moines Twitter Trends