September, 2009
I think one of the most challenging things about building software to meet real business needs is the sheer number of choices you have in how to go about realizing a particular business goal. Here is just a small list of the things you have to worry about:
Are you going to build it as a web application? a rich client? or maybe both.
If you’re building a web app:
What browsers will you support? IE? Firefox? Safari? Opera? Will you support mobile devices? Which ones? Will you have a dedicated mobile version of your site? What technology will you build your site with? .NET? Java? Ruby? What about the many tool kits ontop of those core technologies? Googles Web Kit? ASP.NET? ASP.NET MVC Framework? Ruby on Rail? What languages are you going to use? What kind of servers will it run on? Windows? Mac? Linux? In the cloud? Hosted? Database technology? How will you handled off line devices?
If you’re building a rich client app:
Will you support mobile devices? Which ones? Windows Mobile? Palm? Android? iPhone? Will you support full desktop devices? Which ones? Windows? Mac? Linux? Which versions and flavors? Windows XP? Windows Vista? Windows 7? Windows Server 2003? Server 2008? Server 2008 R2? All the versions of OS X 10? Which of the many flavors of Linux? Is there a server side component for the rich client to sync with? Where is it running? In the cloud? On a server you control? Hosted? What OS? What database? Oracle? MySQL? SQL Server? Virtualization? What technology is it built with? .NET? Java?
The list goes on and own - it’s like a choose your own adventure book. And then you start mixing and matching technologies. And each of these technologies is moving forward with new versions - sometimes that path forward is easy, other times it isn’t. But the technology that you choose really does matter. And the tools that help you use that technology really matter too. They are difference between success and failure. But the real kicker is that your choice also has to match with the culture of the organization you are working in/with - as crazy as that sounds. People’s emotional response to different technology can make or break a project. It’s the difference between someone staying up all night to work around some bizarre issue in a technology they believe in and love vs. throwing their hands up and saying ‘see, we should have used blah instead, this will never work’.
We as developer’s aren’t any help either. The grass is always greener on the other side of the fence. There’s always something new to try. There’s always the next great tool, framework, language, abstractions, etc. We love trying new stuff, new versions, new architectures. In part, these desires are essential to our field, but we need to be challenged in our decisions more often.
If you look at our sales slides that describe the mNOW! Mobile Framework, they are littered with a dizzying array of technologies - each with their own dependencies, acronyms, and versions. In fact, if you dived into each one of those technologies you’d find another massive layer of things that that technology is built on, and so on. In part, this is the very essence of software abstraction. It’s the magic black box. The thing I’m talking about though, is the sheer number of black boxes and how you mix and match and decide between them to achieve your goals.
Let’s look at all the layers in a simple mobile application built on top of the mNOW! Mobile Framework. For the device-side application we support almost all Windows Mobile and Windows operating systems, we build apps with mfLY!, which is built on the .NET CF and .NET Frameworks respectively. We use log4net as our device-side logging framework. For smart devices, we often use Resco controls and on the full Windows devices we use DevExpress. Many applications use bar code readers or RFID scanners and the associated hardware and software stacks. Our applications store data locally using SQL CE and SQL Express. We use ADO.NET, LINQ to SQL, the EF and our own custom OR/M layer built specifically for the Compact Framework. All of our applications sync data using WCF web services and/or Sync Services and/or replication and/or some internal sync technologies. We often use some of the functionality in the OpenNETCF framework. On the server and integration side we support most Windows Server operating systems (Server 2003, 2008, 2008 R2). We use SQL Server (05 and 08) extensively. Our server side software builds on .NET 3.5 SP1 and leverages WCF and WF. We have an integration engine that runs as a Windows services, and a variety of ASP.NET Web sites and WCF Web services hosted in IIS (6 & 7). We use many of the P&P enterprise application blocks. We use LINQ to SQL, EF and our own DAL. We have rich client administrative tools built using .NET, CAB, the enterprise library, DevExpress, Northwoods, Dundas that also leverage WCF web services. Our installers leverage WiX for the client and server applications and cabwiz for the devices. To keep track of all this stuff we have an internal Wiki where we keep track of the versions of all these tools that we are using and general guidance/ best practices for using them. As I get to the end of this I’m realizing that this doesn’t even touch the development tools that we use to create this software! The mess above is just for the end runtime application.
And at a certain point, you come to realize that the technology that you are using has issue XYZ or doesn’t support ABC. This is the moment of Joel’s leaky abstraction where you can no longer go on using this piece of the system as a black box, because it’s abstraction has failed you in some way. All of a sudden you need to understand what is inside the black box and in some cases you have to dig into all the black boxes inside the leaking black box to really understand the issue. Where I get caught up here is that at this point that those alternative black boxes start to look really shiny. I’m talking about the other components or technologies available that address the same problem. I’m positive that the black box alternative to the one I’m using doesn’t have issue XYZ and I want so badly to ditch my black box and use another one.
Part of Vista’s failure was that the abstraction leaked and all of a sudden we were all painfully aware of low level stuff like drivers, and the complexity of one OS having to handle a infinite number of hardware variations. I was personally never let down by Vista, and while there were many pieces that felt unpolished or rushed out the door, the OS was a positive step forward. It was shocking to the Windows community because one of the hallmarks of Windows has been the amazing backward compatibility support for almost everything in the ecosystem. And while Vista maintain 90% of this, the 10% that it didn’t was painful.
Apple on the other hand is in the business of leaky abstractions and has somehow managed to turn it into a sales pitch. They educate their users on the details of things like their processor architectures, and then as they change architectures the sales pitch changes to why the new is better than the old. They play right into that ‘other shiny black box’ syndrome that I was talking about above so everyone thinks ‘yeah, you are right, PPC is dead, Intel rocks’. They even do this with major versions of their OS (think 9 to 10). I recently upgraded my laptop to 10.6 but my PPC desktop is forever stuck at 10.5 because the backward compatibility buck stops there for PPC machines. Apple literally sets out to create a new black box every few years so that we will all think our current black box no longer cuts it. Now don’t get me wrong, Microsoft does this too, but in moving from Windows XP to Vista just about all of my software transferred completely and functioned as expected. In moving from OS 9 to 10, just about every software manufacture had to re-write their software. With 10.6, Apple is not so subtly encouraging everyone to re-write their software again to be 64 bit.
So where does that leave you as a software developer trying to solve real problems? Now, if the only applications you are creating are mobile fart apps for the iTunes app store, then you probably don’t care about this post. But if you are creating real line of business applications then not only do the black boxes that you choose matter, but your willingness to stick with them even when they leak matters even more. You have to keep building on top of what you’ve already got. It’s the only way to create lasting business value. There are some very good reasons for upgrading software or moving to a different vendor. I think every developer should create a list of what these acceptable reasons are. Certain features may be critical to creating business value. Security is certainly a reason to stay up to date. Bug fixes that are getting in the way of meeting your requirements. It would be a good activity to enumerate this list of good reasons to upgrade your black and a separate list of good reasons to ditch your current black box and use another. Otherwise, I think the grass is green enough on your side of the fence.
