Pramatr Blog

Reinventing the wheel and the Not-Invented-Here Syndrome have been widely documented in the software industry. Some companies write literally everything from scratch; defect tracking software, time reporting software, wiki software, you name it they write it! Others want complete control over all their application libraries so if a framework isn’t approved, instead, they’ll just write their own.

I caught up with a developer earlier this year who was telling me some of the stories he’d heard over the last couple of years. This article is dedicated to one of the stories he told me.

Developer X had just started a new job, and his first project was based around writing a criteria style query language to gather data from a legacy database (hosted on MySQL). After programmatically building a criteria object, the code had to generate simple SQL and also more complex queries including like, or, and, in, not, pretty much the full range of query options. There were a few projects that came to mind, but the first was the Hibernate criteria query API. It seemed like a good fit, and this is exactly what the developer had thought as well. He didn’t realise however that he’d joined a team which suffered from the Not-Invented-Here Syndrome.

Developer: I think we can shorten the development time for this project significantly if instead of writing our own criteria query API, we use Hibernate. We should be able to get a prototype of this up and running in a couple of hours. It should take a lot less resources and we could get to market much quicker.

Team Leader: I had a quick look at Hibernate, but we don’t want to update any data we only want to query it.

Developer: So let’s just use the criteria API, we don’t need to use everything Hibernate has to offer.

Team Leader: We don’t want to change our application to deal with the lazy loading issues that Hibernate causes and this will also cause performance problems.

Developer: Hibernate 3 did introduce lazy loading as the default, but this can be changed in the mapping. We’ll just turn it off. As for performance issues we can eagerly load as much or as little data as we want.

Team Leader: Yes but we can’t change our objects to comply with Hibernate’s requirements. We can’t add a default constructor and we use Array’s not Collections. We really don’t want to make our objects managed by Hibernate. Anyone could update a property and it would be automatically saved, we only want to query the data.

Developer: Hibernate places very few requirements on your objects, we shouldn’t really have any problems. If you really don’t want us to use them let’s use something like dozer to map our Hibernate entities to our existing objects. The Hibernate entities can be dumb data holders and we can even use the mutable setting to stop them updating the database.

Team Leader: This will introduce too much duplication, we have over thirty objects we’d need to duplicate.

Developer: More duplication than writing a framework that already exists, is widely used, tested and mature?

Team Leader: …………. silence

The developer decided to try and get the team leader buying into the idea by developing the prototype. Outside of hours, he found the most problematic parts of the schema and made sure they could be mapped to Hibernate. Sure enough after a few hours he had a prototype that worked and actually delivered more functionality than the scope of the project. This made no difference to the direction of the project however…..

Team Leader: We’ve already spent over a month designing and developing our solution, we aren’t just going to throw it away now. Our solution will be much more extensible than Hibernate and the developers will have a better understanding of the code because they wrote it. Our solution will be better as well as we’ll develop better quality code.

The project rumbled along for a number of months, the code was good quality and it did meet the requirements. It was only a little late and had pretty good test coverage. The second round of requirements were hammered out and were successfully delivered a few weeks later. All in all it was a success for the team, they had hit their numbers and they had produced a good quality product.

Although the project was treated as a success, it did however only implement a fraction of what the Hibernate criteria API supported. The team was maintaining many thousand lines of code which already existed and several more iterations had been planned to implement yet more functionality that already existed in the Hibernate Critieria API. The team still hadn’t met a requirement that couldn’t have been solved with Hibernate and I’m not sure they ever will.

So who which of our characters was right in this situation, developer X or the team leader?

Writing something from scratch might sometimes be the right thing to do, but the real skill however is making the right decision with all the facts available to you. There are so many good quality commercial and open source products out there these days (that solve many of the common problems we encounter), but there are still many development teams who continue to reinvent the wheel. There can be many reasons for this kind of behaviour, but you have to address these within the team if you are ever going to overcome them.

From a business perspective you have to be pragmatic about developing things that already exist. Some developers might like writing frameworks, but should this be part of your core business development? Trying to secure your job through domain knowledge might seem important, but having a job to go to is even more important. If you don’t get to market in time this might be a very real possibility. Open source software might sometimes lack visibility, but it has become much more high profile over the past few years. There are many examples of open source projects that have become pretty much industry standard solutions. The information really is out there if you look for it!

If you are considering writing something which solves a common problem, the first thing you have to do is perform a simple search and see if anyone has been therefore before you! If they have, and the project seems a good fit, do a thorough review to see exactly what you are getting into. Write a prototype, play with the technology, do exactly the same sort of things you’d do if you were writing this yourself. If the project isn’t an exact fit, is it possible to modify the project to meet your goals? Will this still save you time and money? If the answer is no, or the project doesn’t fit at all, it might still give you valuable ideas and insights into your own solution. This really shouldn’t be considered wasted time, you are always learning!

Above all, resist the temptation to just reach for your IDE of choice and start coding, do some research and potentially save your team lots of time and money! If you really don’t find anything at all out there, congratulations you might just have found the bleeding edge.