Crossing The Finish Line: Can A Software Application Ever Be Done?
Wednesday, March 26, 2008 -
Had an interesting conversation the other night with a buddy of mine wherein we were wondering if it's possible that an application can actually be "finished". By "finished" I mean it does what it's supposed to do, does it well, and delivers the value it's promised.
I used to think about this with the Commerce Starter Kit. In fact it's why I stopped working on it for the most part - I just couldn't figure out what else I wanted it to do without a full rewrite.
Of course there will be bug fixes - but at that point it becomes "Tinkerware" (meme dibbs - I like this term) and the if you're disciplined, you're driving to completion rather than opening up more bugs. So I have to ask:
Can software just be done? Or are we inventing work for ourselves?
This question comes up a lot in Open Source. I referenced the Commerce Starter Kit above and I think it's a good example. ECommerce has been done, and done again and no one will ever really add value there.
My goal with the CSK was to make it easy for developers to create a store, and to try and get you to "80%" as quick as possible. We went through 2 major versions (which gave life to SubSonic) and at one point I remember telling Chris Cyvas (who has taken the project over and renamed it dashCommerce):
Can we just park this thing and be done?
I was partially joking - I knew at the time that there was some work to do in terms of refining and updating, but there was a part of me that wanted to move on to other challenges.
Builders pound the last nail in, mechanics tighten the last bolt - can't we spin the last byte?
I asked a client once (just 3 years ago) why they were still using classic ASP and they said "because it works for us". It's the best answer possible, from a client-perspective. But I had to wonder about the dev guys who worked there. Did they like working on ASP classic?
Turns out they did - in fact they laughed at me when I told them of all the innovation going on with .NET.
"That's great. We make about $1.2 Million a month with our online store. Will .NET make us more money? Adding features to our system is pretty easy - we all know the system really well, it's documentation is very complete, and it does all the things we need."
In short: they "parked" their application: they opened the doors and lowered the tailgate, turned on Journey, and fired up the barbeque.
Is this sort of thing possible with Open Source? Would you continue to use a bit of Open Source software if the dev team "parked" it and said "we're done - this works. Thank you and good night!"
No, I am not thinking about SubSonic :). No really - please don't ask ... this isn't about SubSonic.
What do you think?
"Builders pound the last nail in, mechanics tighten the last bolt - can't we spin the last byte?"
Even after buildings are done, people want to change them. I know there are lots of changes I'd like to make to my house - make this room bigger, add some space here... but it's hard to do that.
With software, it is much easier to make changes (compared to modifying a building). Hence, we are constantly modifying our software to better do what we want it to do.
I think its more of a question of human nature - can we ever be completely satisfied with something? To just "park" something and stop working on it to me seems like a loss of interest in the project more than anything.
I don't think this is something specific to software development, though. The same logic could be applied to any field.
I think a good example of this is Synergy (http://synergy2.sourceforge.net/). It's latest release is April 2, 2006. It seems to have been parked, and yet I use it and continue to use it happily.
No, it can never be done. There are always new runtimes to support, new language features to expose, etc. If you shipped an OSS project in .NET 1.0, parked it, then you might have a bunch of custom collection types that can't be worked with easily as they don't implement IEnumerable<T>.
Another (albeit incorrect) perception is that unless there has a been a release in the past year, the OSS project is dead and should be avoided. I've run into this many, many times with projects like Spring.NET.
I hear it all the time. "Hey, should we look at the Floogle project?" "Well, it doesn't look like it's under active development"
With OSS, so much depends on the community for support. Communities seem to gravitate towards areas of active development.
I'm sure there are some exceptions though...
Parked things stale painfully. otoh, beware the bleeding edge.
And as a developer, sure, 1.2 mil/mo, Bring on the classic ASP. But when my motives aren't profit but something else, I'll prefer to work closer to the future.
Good points - all :). It's the same conclusion I came to with my friend.
I understand the House issue - but most of that is wear and tear from the environment - something software doesn't have (aside from hardware clashes over time).
Do we really need to keep changing colors?
OMG, this is *totally* about Sub Sonic isn't it?!?!
But seriously...
I think there's a good analogy with a car here...
I bought a 2007 Toyota Rav 4. I love it...it has all the features I want, suits my needs, and makes me happy.
Next year, Toyota will release a new version. And a new version after that. And a new version after that. Rinse and repeat.
Now unless my last name was Gates and I just loved supporting the automive industry, I'd be crazy to want to get a new car *just* so I could have the latest and greatest...especially when I'm happy with my current vehicle.
Same with software: upgrading for the sake of it makes no sense until you get to a point where the cost of not upgrading becomes larger than the cost of making the move.
One thing I'm always floored with is the disconnect between my expectations and those of the clients. I always think they're going to be disapointed unless they have the most amazing, robust system...when all they really want is something that meets their needs. Maybe that's our own dilemma: we're so used to being fed new versions of Office, Visual Studio, and Windows that we assume our customers are expecting the same thing from us?
Anyway, just some thoughts...
D
No. Software can never be done. Just go ask your boss.
A few projects ago, I worked on www.Statsworld.com. This was an internal project at Business Integration Group for us to develop a public case study for our .NET development practices. After 9 months of development, we started our first football season and we all rolled off the project.
It's been almost 5 years since then and there hasn't been a developer assigned to the project since. It's running ASP.NET 1.0 (we didn't even upgrade to 1.1). The application services roughly 30,000 users each season, and there hasn't been a bug submitted in a few years.
The project served its purpose, allowing us to showcase what we can do to provide highly-scalable software that meets tough demands (1 million ASPX page views every Sunday during NFL season). The users love it, and we get new customers every year, without an ounce of development or marketing.
Disclaimer: Statsworld was a port of a thick-client application that Business Integration Group had been selling for over a decade. So the requirements were pretty solid.
rob = rutgers fan?
I've always heard it takes about 10 years for an app to reach maturity. You can always tell because each new feature takes away from the functionality rather than improving it. So, if you've been working on the same app for 10+ years it's probably about done.
On the other hand Germans thought they had perfected the automobile until the Americans said "We could add a cup holder and this thing would be awesome!" Without the cup holder, where would we be today?
"ECommerce has been done, and done again and no one will ever really add value there."
The average online store converts less than 3% of visitors to customers. I'd say there is plenty of room for innovative companies to add value to ecommerce.
I don't think software is every really done. It can always be better. That doesn't mean you have to improve it, but at a certain point it does the job and it might be time to move on.
Anyway, the real reason for the comment....where did you find the pic of Rutgers? That rocks! :)
I'd argue that with every check-in or revision software is done. Just like the builder who pounds his last nail or the mechanic who tightens his last bolt.
The problem in terms of software is you are always working on the same car or house for the same person who is constantly adding on or upgrading and in the OSS world you are working for free so it seems like there is no end and it is just one giant blurry project, instead of individual distinct projects that you finished.
As far as the need to keep doing upgrades and improvements we probably don't need to constantly upgrade, but it sure is a lot more fun and makes our lives more enjoyable. An 8 year old monochrome cell phone works just fine for making calls, but I'd rather be selling shiny new iphones to people whether or not they really "need" it. Sure we can do just about everything we do today with classic asp, but it sure is a lot more fun and easier to throw silverlight in their face and try to convince them how much they need it.
I think on word that has been missing from this discussion is "business", which relates back to the ASP verus ASP.NET website that didn't want to upgrade. It didn't make business sense. As developers, we always see a need to upgrade and are excited by new features, be they actually visible to a user or not. The projects that I can classify as being done in my view are projects that no longer make business sense to upgrade or maintain; basically there's no client that wants to do it or no clients that will purchase because of it.
+1 to Tom B.
YES, business software can be done. I wrote a scheduling application while in college on ASP 3 and SQL 7.0. It has not been modified in 11 years, and it still schedules 40-60 events per day.
NO, techical software can never be done. If the consumer of your software are fellow engineers, it can *always* be improved. If your software is open source, it *will* always be improved, because someone, somewhere will scratch an itch that nags them.
+1 to Jeremy Coenen for cleverly breaking grammar rules to make a point. ;)
+1 to Rob for switching the blog to Graffiti. The Subsonic project copyright is still at the bottom though...what kind of magic is this?
I don't have a real answer.
If it saves me time, I'll use it. If I can change it myself, I'll use it more. If I can share my changes with others, I'll use it just as much as before--but I'll feel better about myself so I'll actually work harder, which would entail using it more.
It's never done because it doesn't have to be. When was the last time your client/boss *insisted* that you stop improving the app you built for them. And because our 'final' product is not of the physical world (the last bolt to tighten is only a metaphorical bolt) we *can* keep working on it with relative ease. That said, really finishing something and 'firing up the bbq' would provide a nice sense of closure that we rarely get to experience.
Very interesting question. It makes me think of Word 97. Why did it have more releases? Why Word 2000? Why the current release? Did it improve? Did it add features you need?
Well sometimes it improved and made live easier. Most of the time it did not and it was just the same product with just more bells. After Word 97 the product just got worse. They should have stick there and maintain it for bugfix sake. So why did you continue to create new release aka why a new CMS? From a commercial point of view: make more money and try to make it a bit better. From a OS point of view just to make it better by incorparating new ideas/techniques.
Like Pwills, one of the first apps I built took about five times as long to write as we thought (in-house, luckily), was subject to some tinkering for six months, then has remained static and in-use as far as I am aware since 1997. It simply does exactly what the business needs, very elegantly.
What really makes me angry is when programs like this are subject to forced reworking due not to any real obsolescence, but just the relentless marketing-driven change 'for the sake of change'.
I often pine for the days of old ASP where things were simple and I didn't have to use umpty-gazillion widgets to get 90% of the way in 10% of the time, and then spend the other 90% of the time working around the fact that the structures the widgets need are too rigid to get me the remaining 10%.
I think ASP .NET is only compelling when it is used for new projects, and once we have redesigned half the System.Web.UI components to do something half useful. The current state of ASP .NET is the result of simply a fashion to have way too many clunky objects around which don't really help design that much. Mark my prediction, twelve years from now the toolsets will be made up of many fewer components, which work much more elegantly and flexibly.
I have been saying for some time that there is only a limited number of things you can do with a computer language and toolset, and we are fast approaching an endpoint, or convergence if you like, on both toolsets and languages.
6Pac has great points, although I wouldn't necessarily call old ASP "simple" ;)
I totally agree that ASP.NET has been marketed to the majority as almost a WYSIWYG type of interface where you can drag and drop to your hearts content to create an application that is horribly difficult to extend or modify in the long run (had to re-do a web app recently that fit this exact scenario).
What would be nice (although probably not feasible from a business model) would be to halt new language features for longer than a couple of years...like, maybe 5 or 10. Instead of giving us new *features*, we really need to educate developers on best practices, patterns, etc.
I think the MVC framework is a great step forward to this. Yes, its not the first MVC framework and no Microsoft didn't invent it...but let's face facts: there are many developers out there who won't evaluate products unless there's, in their view, a reliable and valid vendor behind it. If the MVC framework brings more people into the mix of better practices, then that's a win for all of us.
Anyway...a bit of a tangent from the original topic...
D