Unmet Promises and Unwanted Complexity

I’ve been mulling over the my use of use of a third-party libraries, both long term and on my last project. On the former, a core library I use has made a disastrous UI decision that needs fixing before I can release the next version of Toucan Reporter. On the latter, the client had pre-selected a well known, mature and comprehensive looking component library that they wanted to use for both web and Winforms applications. The demo applications make it look easy to develop fantastic looking line of business applications.And its this library I want to talk about today.

It sucks.  Here’s why:

1: Unmet promises. In several areas of the product, there are features that just plain don’t work in the real world. In particular, there’s a designer for quickly laying out Winforms pages. In this designer is the ability to add tabs. If you are going to  use this feature, the chances are that you’re going to use it to build a form with a good number of controls on it. Problem is, that as the number of controls increases, performance goes down rapidly. If you have more than a couple of dozen fields, then you’re looking at a wait of tens of seconds as you move controls around. Part of the problem is the management of undo/redo operations. Rather than use the one built into Visual Studio, they’ve created their own, and the performance is terrible. You can turn off undo/redo, which improves things a bit, but its a hack.  At some point you’ll be even more committed to this approach and you’ll be having the same performance problems. At run time, performance is great, by the way.

2: Unwanted Complexity. Controls are objects. Objects have properties, and in the .net world, there’s a bunch of standard controls with consistent properties, provided as the .net framework.  The implementers of this particular library, however, used different names or different properties or different enumerations throughout their library. A stand out feature was the use of a property called ‘Properties’ that happened to have most of the useful properties for the control in it. Almost every time you needed to set something in the designer, you have to go through an unwanted step of opening up this Properties property to see the property you wanted.

3: Locked in or Locked out? The implication of having an unnecessarily complex component library is that the hapless line of business developer using the package (me) is simultaneously locked in and locked out: Locked in to the bad decision  to use this library, and simultaneously locked out of the chance to make meaningful changes to the libraries behaviour. Its impossible to re-do the UI of the application to exclude the complex UI library, and at the same time its almost impossible (given the deadline for the project) to fix the library in places where the behaviour on offer differs from what is required. You’re further locked out of using other component libraries as they won’t share the same styles, making your app look a mess.

Summary: Component libraries offering increased productivity for line of business applications should never deviate from the norms for that environment. Software should be written such that any developer who knows the base technology should be able become effective with the library as soon as possible.