10 signs that you might be in an abusive relationship with your software frameworks and components

Software frameworks and components exist to make the lives of software developers easier and more pleasant. They remove the need to do dull repetitive tasks and allow you deliver business value faster resulting in you being a happier person.

However, we seem to be able to develop some sort of abusive relationship with our frameworks or components. After the honeymoon, small irritations start to occur, but also at the same time, our dependencies on those frameworks or components grow and grow. When realizing the state of our relationship, it’s often too late for an easy way out and the situation ends with a bang (like people quitting their jobs or projects being canceled).

The following list contains signs that you might be starting to have an abusive relationship with your frameworks or components. With no action taken, things will end up in tears. The signs are real quotes from the field.

1. “We’d love to build this feature and we could easily build it ourselves, but we standardized on and they do not support this scenario (yet)” Standardization can be a good thing among development teams, but you can also push it too far. If it’s easy to build by hand, go and build the feature. Don’t let a component suite dictate what your app is capable of.
2. “The next project should go a lot faster because we learned all the intricacies of ” Do you see the word ‘intricacies’? That alone should put up a big red warning sign. There better be something very special about framework x that compensates for those intricacies.
3. “Things are quite rough now, but promised that everything is fixed in the next release” This might sound cynical, but not all will be fixed in the next release, for sure. You have to be realistic about what to expect from a component vendor. If you still see steady improvement then there isn’t too much to worry, but when promise after promise is broken, I’d look elsewhere very quickly.
4. “Yeah, we should really upgrade our app to but we can’t because our company framework depends on a real old version of it and we can’t upgrade the framework because that would break almost all our other apps” Don’t use or develop a company framework. Often, companies develop application frameworks to remove the need to build certain features again and again, but over time you’ll notice that existing applications build on top of the company framework become a real maintenance burden. Everything has to stay compatible or multiple versions of the company framework have to be maintained (even to the point where every app is tied to its own version of the company framework). I think it’s a safer choice to harvest the good parts of existing applications and re-implement those in new applications, combined with small set of current developer guidelines so everyone stays on the same track.
5. “They are working on a Visual Studio plugin” This indicates what you might have thought of yourself already: this component is just way too hard to use. Get rid of it.
6. “New developers are productive after about one month because they have to learn our company framework first” See also #2. What justifies an initial one month learning period? What if one of our team members suddenly gets ill and the deadline is approaching fast? We can’t just hire a temporary developer and continue.
7. “No, this nasty bug still isn’t fixed because it’s somewhere deeply inside our framework and the original developers left, sorry” Frameworks are usually meant to facilitate a broad range of applications and can be fairly generic, abstract and complex. It all made probably perfectly sense in the heads of the original developers but without their guidance we’re lost. If you have an application framework, the least thing everybody needs to know is the underlying vision of it.
8. “Yes, we know it’s slow as @#$% but we can’t make it faster unless we completely bypass . Did component y threat you not to use a better suited alternative? I don’t think software components do that. Bypass it immediately. There is no excuse for a slow application.
9. “It’s so flexible, you can configure everything in XML” What this really means is “it’s so flexible, you have to configure every darn little thing in XML and you won’t have any free time left, ever”. If possible choose sensible defaults and cut down on the configuration as much as possible.
10. “I hear that is cancelling . Did you see that coming? And didn’t we base our entire product on that?” It looks like your significant other has left you the cold. You have been in a relationship with a liar and a cheater without even realizing it (those cases of #1, #2, #3, #5 and #8 were actually a sign). Take your loss.