Sunday, October 31, 2010

The hardest problem with computing is people

Gilad Bracha said this during the Programming Languages Panel at Microsoft PDC 2010.

The hardest problem really is this whole issue of compatibility that plagues software, that is so brittle, you can never take things out, you can never fix things early, you can just add stuff, and therefore contribute to bloat and the problem is not so much with the technology as it is with the people. The hardest problem with computing is people, and you know they need to be replaced but we cannot do that. Ultimately we need to find ways for software to evolve and update itself in such a way that it can not only grow but shrink.

Hopefully I'm not misrepresenting Bracha or quoting him out of context when I say this.

I've been looking into software composition and clearly found great use for dependency injection. Inversion of control IoC (IoC) represents a step in the right direction and dependency injection (DI) is the means to achieve both IoC and composition. As a proof of concept of this, I was refactoring some code written by co-worker this Friday, moving things into reusable services, and surprisingly yet satisfyingly so, I'm removing more code than I'm adding. The result is not necessarily a smaller code base, but the complexity is certainly more manageable (on top of being testable). I think this is what Bracha is getting at.

The benefit is that there's no longer a tight coupling between these objects. Which is what's allowing me to actually move this code into a separate assembly altogether. If I can partition my software into isolated compartments then that's a step in the right direction. What you get out of this is a problem which focuses on the management of several smaller instances instead of one very large code base and through experience, I've learned that managing complexity on a smaller scale is preferential to a big ball of twine (intermingled dependencies).

The compositional approach is of course not free. Nothing, is. For one, a loosely coupled software architecture that is compositional requires lots of abstractions and you should be aware that there's a fair amount of work to be done to orchestrate the composition of the software itself. Some work is going to focus on writing auxiliary software to make deployment and configuration easier.

I'm convinced that composition is the way to tackle software aiming at solving a diverse class of problems in some manner which is consistent on a higher level. It enables great flexibility without sacrificing architecture, testability or maintainability at the cost of initial bootstrapping when new requirements surface.

No comments: