Web and Mobile Software for Agriculture Business

At the time we were approached by the owner of an agricultural business, he had invested two years and hundreds-of-thousand-dollars in a web-based software product he was taking to market.

He felt like he had done everything right. He hired two experienced developers, one to oversee the development and the other to help solve some of the bigger technical challenges, as well as a local development company to do most of the coding work.

The problem he experienced is the software the team produced was very buggy and very difficult to fix. The team had spent months trying to get it stable enough to launch but just couldn’t get it done. The owner finally decided that it would never get done so he fired the dev shop and one of his developers and started looking for other options.

He found us through a referral and asked us to take a look at the code and give him an honest assessment of where things stood.

When we started digging into what the previous team had delivered, we found the code was much more complicated than it needed to be and was very bloated.

The software was built on Microsoft’s Application Building Blocks which may serve a purpose in some rare situations, but we’ve never seen a need for it and never used it. Since we normally don’t use those tools, we couldn’t offer a predictable timeline on getting the code stable so we took it to a couple of high-end Microsoft shops we know. Neither wanted to touch it because they didn’t feel they could be predictable with estimates either.

So here sits an owner who thought he was doing everything right only to discover two years later that he had wasted a lot of time and money on code that nobody could figure out. His development resources had made some very bad decisions early on and unfortunately it took a while to figure that out.

This happens far too often in this industry.

Software development is very faddish. There’s always something new to try and sometimes developers feel if they don’t use the latest thing they’re doing their client a disservice. In reality, the exact opposite is true and what clients want most is a stable, well-built, extensible foundation to continue to build upon as their business grows. This is why developers have to be managed.

In this case, we gave the owner two options: we could take the place of the previous team and try to fix the code not knowing how long it would take, or we could rewrite it and get him to market in less than six months.

He chose the latter.

Our rewrite was less than half the size of the original codebase even after including features that the original team could not deliver, and it is code we can easily train new developers to maintain and extend.

We’ve been working with this client for almost two years and look forward to supporting its endeavors for many years to come.