Thursday 7 August 2014

Complexity in software development

I see a lot of programmers online these days complaining about their craft these days. I think some of them are getting close to the heart of the matter. For me, the problems in programming usually come from third-party dependencies. That's it. We have complex tools to manage them, because we need to, and we have lots of options for this or that functionality because it's difficult to figure out how to work with some libraries, or it just feels easier to write your own. Depending on one third-party library might not be so bad. Depending on several, especially when they all depend on different versions of some other fundamental library, is where it gets tricky.

Soon, rather than hearing about Agile software development methodology and tiered architecture, we may start hearing about designing software specifically so that it is easier to work with third-party dependencies. Maybe each layer will be split in two, with a dependency module to hold all the third-party tools it needs, and a nicely-engineered facade for the rest of the program to use. That's just a thought. The main point is that, for me, the complexity and frustration of software always seems to arise from third-party libraries and frameworks. While they give us power, they add integration complexity.

I work mostly in .NET, where apps can be nicely architected into layers and complexity hidden, if needed. I imagine this problem is much, much worse in everyone's favourite "modern" development environment: unstructured HTML+JavaScript. In that environment, you can't even tell if your third-party dependencies will still be there when you run the code, let alone whether they will destroy each other by trying to define the same things. Attempting a big, modern development project with JavaScript would be the opening of a horror movie, for me. JavaScript does not want you to succeed.

Mokalus of Borg

PS - Yet people do it.
PPS - Somehow.

No comments: