We're building better mousetraps!

The term "debugging" within the context of custom application development refers to the process of ironing out the kinks in the underlying logic of features so that the features behave as they are intended to. The term itself grew popular in the 1940s, the heyday of IBM's Thomas Watson Sr. who is rumored to have opined "I think there is a world market for maybe five computers," an era when the computers filled large rooms, contained vacuum tubes, and frequently were literally hindered when insects got caught it their apparatuses. Debugging is common and ultimately a necessity in traditional approaches to custom software development where code will always have unexpected errors.

Headspring Systems own approach to vermin extermination is a proactive one. We curtail almost all need to debug by keeping the "bugs" from ever appearing in our applications. We do this by way of test-driven development, a staple of modern programming.

Every class written which is not ensured by unit tests is a new piece of legacy code at birth, a harlequin trickster which may or may not do ONLY what the comments sprinkled within it imply. Surely, a change to the CRM won't affect the shopping cart it is coupled too, right? Well, if you're flying blind without tests there is really no way to know other than the hard way, and if you do realize there is a problem there is going to be a lot of heartache in pinpointing the one or two lines of code in need of addressing.

Headspring offers the opportunity to build software a better way, using modern industry-standard practices including test-driven development, guaranteeing that as your code base grows that the existing code can support additions and that the changes do not have unforeseen consequences.

If you've ever found it a challenge to hire a second contractor to revise what an original contractor has begun and wondered why the original "talent" left such an untenable mess the answer most likely lies in an upfront desire to get results quickly, cheaply while foregoing unit tests. The safety net of TTD is vital. Its presence or lack thereof signifies the difference between good software and bad. If you have had a bad experience we hope you'll select your next vendor with test-driven development in mind.

Contact us: We're the smart choice.