I’ve been trying to write a web application in my free time. It’s been going on at varying degrees of intensity for months now, and I’ve got virtually nothing to show for it. Part of that is due to a lack of time to devote to it; at best, I can add 2 hours to the top of my day by getting up early.
But the point of the post is really the other compounding factors that the various technologies impose on me, and how that relates to the client perspective in typical contracted software work.
My day job involves almost exclusively Microsoft technology; .NET in particular. We use Sharepoint to build client intranet applications, do custom C# development, etc.
In my hobby projects, I tend to play on a Linux platform with Lisp or C++ (although I certainly am no stranger to the Windows platform or other languages). The webapp I’m working on has been based on Weblocks, a continuations-based web framework for Common Lisp. I have an idea of what I want it to be and do, but Weblocks isn’t well documented and I’m not very experienced with it yet, so I come to it asking this question:
what can I do?
The framework is also pretty liberal, so even once I know what it provides, I still have the same question because the possibilities are limitless. In a way, this expanse is paralyzing: I have to spend a lot of cognitive energy figuring out among the zillion design choices at each step, in addition to learning a technology I’m inexperienced with. Consequently, it takes a really long time to get something working. However, once it starts to roll, it can roll fast because once I’ve made my design decisions and worked out my requirements (informal as they may be), I understand where I’m going and generally how to get there.
I have another hobby project, a Git client for Windows built in WPF and C#. With that project, I ask a different question:
How do I do that?
This is because of the nature of the platform. True of closed, proprietary platforms in general, but in particular of comprehensive frameworks like .NET, most of the design decisions have already been made. I don’t have to choose among the zillion ways to render a components in HTML/CSS/Javascript and process user activity – there’s already a mechanism just for that in ASP.NET called “web parts”. I don’t have to make a hundred design decisions about the desktop GUI framework to use and how to use it or roll my own or extend one, etc, because the Visual Studio and Blend designers support WPF. With this platform stack, the tradeoffs are reversed: I can get rolling on a project almost immediately, but at some point, things get really hard because of the box you find yourself in down the road (and at least part of the box is hidden from you because of the proprietary nature of the stack – the Sharepoint object model is a perfect example because it sucks). I once worked on a system that had it’s own threadpool because the .NET threadpool didn’t perform well enough, for example. That was not a quick project.
What struck me about this contrast was that I found myself empathizing with the position of a client.
As in the first case, the possibilities are endless – unmanageable – at first, and I didn’t know what I wanted, and nobody was there to tell me – but later on, the freedom in those design choices was favorable.
In the other case, I had some very concrete ideas about what I wanted because the technology limited my choices, but those limitations created pain points later on because they became very confining.
Conclusion? I don’t know, really. Each position has it’s advantages and drawbacks. I tend toward the former as a craftsman, but toward the latter as a consultant for a variety of reasons, including market inertia.
