Complexity in Universal Widgets
I had one of those complexity experiences this week.
I was doing some software development. Small project. Small personal project, I’m the only one working on it. However, I still managed to end up in a game of whac-a-mole.
Image source: Flickr with license
The situation:
I was using a widget created by someone else.
The widget was not built to do exactly what I needed.
I decided to use the widget for multiple things.
The nature of the widget means there are some properties that are statically defined and cannot be changed at run time.
I parse the input parameters that include a type, and based on the type, I set some other parameters.
So it was working well, I was feeling good, then I change something, it blows up. I address the reason it was blowing up, and then something else blows up, and on it goes for a frustrating period of time.
In the end, it turned out to be a combination of the interaction between type-dependent logic, the statically defined properties, and some logic in a callback.
My development discipline could have been better. I was tired at the time it blew up. I probably should have stepped back and seen the big picture of what was going on instead of a series of fixes, and maybe a couple of other common sense things. Whether I responded to the complexity as well as I could have is one thing. The conditions of the complexity are another.
Numerous times in my life, whether I’ve had a business hat on or a development hat, there has been the question of whether I should recommend/use a third-party package, or whether the thing needed, had to be written in-house. These are not easy decisions.
In the case of the above, the widget is probably core enough to the value-add I am pursuing, that I should probably write it myself. Deciding whether to bite that off in a prototype or bite it off later is another question, but probably the sooner I write it myself, the better (alternatively I could instantiate at runtime multiple different versions of the same widget, with different properties).
It was a reminder of the kind of complexity that can emerge when a) you use one widget for many different things and b) the widget is not purpose-built for what you are using it for, but is close. For sure, there are better software developers in the language I am using (which I am still ramping on), and there are better software developers in general. However, other software developers have also to deal with the complexity of hundreds or thousands of engineers hitting on a code base, or similar code bases.
None of this is to say that one widget should not be used for different things, but it is to say design is important, and whether you utilize widgets purpose built for what you are doing, may also be important.