Headspring’s latest new hire is Cedric Yao, Senior Consultant.  We’re really excited to have him on board, and I am super excited to get a fresh addition into this series.

Cedric has been in Austin for a few years, and just welcomed his first born son into the family 5 weeks ago!  We talked about Austin, why working here is so much fun, and what we really love about technology.  As it turns out we share a lot of the same interests in bringing together communities through technology.  His experiences are going to be a real help to me with planning and preparation for Headspring’s Central Texas Give Camp in September.

Here’s how the rest of our conversation went: Read the rest of this entry »

Most people in the industry are undoubtedly familiar with the Software Development Lifecycle (SDLC).

Reference: Wikipedia

I was having lunch with a recruiter colleague, and I was learning about the QA requests from lots of customers.  Most defined the QA role well within the “Testing” oval as shown in the picture.  From my questioning, it appears that the agile movement has done little to alter this SDLC.  In fact, this process is still alive and very will, even within agile teams.  The difference is in the batch size.  Rather than doing analysis on a batch of 50 features and then moving that full batch to design, the agile movement has reduced that batch size considerably, and in some cases reduced it down to a batch size of 1.  Lean agile teams are likely to use a batch size of 1 and continuously pull features through the lifecycle.  As an aside, I find that even when working on a single feature, this cycle is still in play, although the feature is more likely to jump backward and redo a portion of the phase before if new information is found. Read the rest of this entry »

Alonso Robles is our newest Principal Consultant at Headspring, and has quickly become an office favorite.  He is very enthusiastic about working here, and even wrote a blog the other day expressing this sentiment.  But the thing I’ve noticed about Alonso is that he is enthusiastic about everything – his family, his projects, his clients.  He’s a refreshingly happy addition, and great for conversation.  Here was how ours went this morning: Read the rest of this entry »

According to this is a popular question on Programmers – Stack Exchange, a user once asked a programmer the innocent question, “Why isn’t software as reliable as a car”?

The highest voted and overly pedantic answer is, “it isn’t: cars themselves have software that is far more reliable than the mechanical parts of the car”. I guess that’s what you get when you leave it to programmers to answer such a question.

Maybe some software is reliable, but I bet you’ve used a custom software system that was far less reliable than your car, haven’t you? I know I have. I’ve built a few them in my past. I’ll take my Honda over some custom software systems any day!

Why is my custom software system so unreliable?

Of course, there are several answers, and I am a programmer, so can’t just answer this with a single sweeping generalization. The reason software can be unreliable is as complex as unreliable software is – and therein lies the answer!

At Headspring, we’re big fans of the book “The Mythical Man-Month” by Fred Brooks. It’s one of the most important and influential works on the human elements of software engineering. Even our sales and marketing folks have read it – ask them about it!

There are two passages in the Mythical Man-Month that I believe best answer this question.

Plan to throw one away

You don’t need to be a vehicle manufacturing expert to understand that to successfully build a new car, you need to go through multiple rounds of designing, prototyping, and testing. Early prototypes are “thrown away” each time until eventually the manufacturer has produced a car that meets all of the design, safety and performance goals. Your Camry is so reliable because it wasn’t the first thing Toyota bolted together.

Yet custom software is often treated differently. “Project after project designs a set of algorithms and then plunges into construction of customer-deliverable software on a schedule that demands delivery of the first thing built. …In most projects, the first system built is barely usable. It may be too slow, too big, awkward to user, or all three.” (Brooks, p.116) You’d never buy a car that was the first prototype out of the design shop, but I bet you’ve purchased or used software that is.

One reason the custom software system you use is less reliable than a car is because its creators likely never planned to throw one away. They delivered the throwaway product to you.

Complexity and maintenance difficulty

The other reason software can be unreliable is complexity and maintenance difficulty. “Software entities are more complex for their size than perhaps any other human construct, because no two parts are alike. …software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.” (Brooks, p.182)

It may not seem like it, but in some ways software is orders of magnitude more complex than a car. The mechanics of a car engine are constrained by the physical world in ways that software is not. This complexity also makes it hard to maintain systems.

When a mechanic is changing your car’s oil, you can be confident he’s not introducing a defect in your windshield wipers. When you are repairing a flat, it’s unlikely that you’re going to inadvertently cause your radio to lose its station presets. Because software can be so complex, fixing it is far less reassuring: Brooks suggests that fixing a defect has a substantial (20-50%) chance of introducing another. (p.122)

Reliable custom software

If you have a custom software system that you don’t trust as much as your car, I wouldn’t be surprised. Software can be immensely complex and built in a way the nearly ensures a lack of reliability. And for every bug fixed, another one might be introduced. Custom software isn’t for the faint of heart.

At Headspring, reliable custom software is our specialty. We employ agile and test-driven development methods to mitigate the challenges of custom software development. Most importantly, we understand that our job isn’t just to build software, but to deliver satisfaction to our clients. A reliable system is worth little if it isn’t the right one for the job.

Chris Missal, Senior Consultant at Headspring, is our newest addition to the team.  His background is mostly in web development using ASP.NET and MVC in the eCommerce industry.  At his last job, J&P Cycles, he helped create a system for allowing third-party widgets to more clearly communicate with each other, therefore allowing his team to better understand and utilize information picked up from visitors of the site.  Yes, Chris is the guy that knows how to see everything that you see on the internet.  But for good, not for bad!

And his interests don’t stop there.  He’s currently learning Python, and along with coding, he likes disc golf and bowling.  He just moved to Austin from Iowa, and is really looking forward to getting into the social scene.  “The developer community is so lively here that I’ll be looking to get involved with groups that are passionate about making their communities so wonderful,” said Chris.

Here is how the rest of our talk went: Read the rest of this entry »

Since I’m new to Headspring and we are hiring, I thought I would help give an edge to anyone applying and subscribing to our blog. There are many “features” (pun attempted) that make up a Headspringer and I’m hoping my fellow Headspring bloggers will help me verbalize them through the “Becoming a Headspringer” blog series. I will be starting this series with some quick tips on ReSharper. If you do not already have ReSharper or know what it is, immediately after reading this post is as good a time as any to try it out. Read the rest of this entry »

Once upon a time, a problem was identified. Shortly thereafter a solution was found. After all it wasn’t a tough problem and the solution was simple. A commercial framework was selected and the solution was implemented. Then it was re-implemented with an open source framework and then rolled back to the commercial framework. Both frameworks were evaluated and the findings revealed both frameworks had the features and functionality to solve the problem within the context of the solution. So what was the reason for indecisiveness? Read the rest of this entry »

Deran Schilling, Senior Consultant at Headspring,  is new to the team, and we have warmly welcomed him in as an additional web technology and design enthusiast.  After working in education for several years at LSU Alexandria, and Clear Creek ISD, Deran has gracefully transitioned to the corporate world and the Austin tech community.  So far, he has lead a team of Headspringers to participate in this year’s Knowbility Austin AIR, and has plans for more events and competitions this year.  Here is some of our conversation:

What led you to software development? Read the rest of this entry »

This week I was pleased to sit down and chat with Nolan Egly, our newest Senior Consultant at Headspring.  Nolan has been working as a software developer in Austin for years.  He was hired here at Headspring after being placed on our famous internal spreadsheet that lists our employees’ “dream” coworkers.  That is, if you could work with anyone, who would it be? Apparently it’s Nolan!  Read the rest of this entry »

From what our coworkers say, Senior Consultant Brandon Barry can go head to head with Jimmy Bogard about the internals of the .NET framework.  Recently, he wrote a library for .NET that allows for dynamic querying SQL databases using LINQ syntax, but with no configuration. You can find it on Github.

All in all, he is incredibly knowledgeable Headspring developer, and is known for his affinity for clean, elegant code.  In fact, he prefers refactoring rather than having to work around bad code.  He is also great proponent for balancing the benefit of tests without sacrificing quality.  Here’s what else I learned today:

Read the rest of this entry »