Application design for 5 years

views:

207

answers:

+3 Q:

Application design for 5 years

My question is not technical. It's more of a philosophical and really down to individual preference. I am designing and developing an application (web + desktop) and this just occurred to me and was wondering if you guys (programmers and designers) ever came across this before:

Some designers believe in making applications that will run 3-5 years down the line and any changes that come to them will be reflected on them without any need to resort to system core changes. As a programmer I know for a fact that this is never the case. Small cosmetic changes do occur but usually they die away after a year or two, as time progresses there will be changes that will require core changes and eventually you will make a new application.

Given the fast paced changes of technologies, designing an application for 5 years down the line is rather absurd, IMHO. Well I mean not designing, but the idea that this application will run for 5 years and the belief that we will not need to create a new one I think is living in a fool's paradise. I mean really, fellow programmers, most mission critical or basic small application that have a running flow usually are re-made/re-structured/re-organized/re-coded few years down the line anyway.

So my question is why keep to this attitude of having this perfect application that will run for a decade. It's stupid really, because you know for a fact that technology will change every year; new frameworks, new methods, new technologies will emerge and your client will want them. So, if you forgive my use of this phrase, WTF is the point?

I keep telling my designer that the application will be redesigned in a few years anyway, there is no point in trying to make it shoot lighting from its @ss because it just won't, ever. There is no such thing as a perfect application.

I hope you guys get my drift. Have you guys felt the same way too. BTW I have been in the software programming business for about 7 years now. If you really think about it, do you really think Facebook will remain the same 5 years down the line, for sure the design will change every year or so to remain "funky" but the core will change every couple of years. I am dead sure of that. Am I paranoid or what? Please tell me there are other programmers in the same road as I am. Anyone?

+8 A:

My approach is to design for change. This means writing the most maintainable code I can, keeping things loosely coupled and modular, trying to do things in as standard a way as possible so that other developers can quickly pick up on the code, etc.

I usually put a little more effort into future-proofing the database design, as changes there can be a lot more difficult than code changes in many cases.

RedFilter 2010-08-09 15:00:58

+1 for being more careful with the database. Making db design changes sucks, even with tools like migrations.

jvenema 2010-08-09 15:04:06

oh yes ofcourse it helps developers really if the design (cosmetic and business logic) is flexible to handle change, but really that can only go so much. It has a limit and in my experience (though only 7 odd years) applications get redesigned or revamped (nearly complete do-over) every 3, 4 years. I don't think there is ANY application uses more then 60% of its original code from its inception.

xeshu 2010-08-09 15:05:37

Exactly. I hate DB changes, but again I can only make it a little flexible, there will always be some dirty nasty changes that will happen down the line in which case you have to decide, should I do this hack and violate all rules or start a do-over. The answer is based on the requirment it self mostly

xeshu 2010-08-09 15:07:04

@xeshu: I have worked on many applications that used 100% of their original code + 200-300% ADDITIONS (but not alterations) after 8+ years.As an aside, you can utilize a design where there is a layer of abstraction between the actual database and the application logic. In this case, very large changes can be made to the data layout without incurring the need for any subsequent changes to the business logic/application core.

acanaday 2010-08-10 15:05:45

+1 A:

I beleive that if the core of the system is built on principles that haven't changed much in many many years, then the system fundamentally will not change much, most changes would be primarially aesthetically.

Some tried and tested principles that remain strong to this day are for example database normalisation, modularisation of code etc etc.

So it depends what you define as the core. For me, the core means the design of the system, which if done properly probably wont change much at all in the future.

Tom Gullen 2010-08-09 15:03:23

DB normalisation, modularisation of code are simply put, standards for the poor man. As soon as the application gets a little complex, BAM! the first thing you throw out the window is the standards, because they stand as a wall in front of you and the end product.

xeshu 2010-08-10 09:30:41

Now you may refute by saying that by violating the standards, I have basically invited my self into a code maintenance nightmare. True! Very true. But had I put in an enormous effort to try to get things according to standards, I would have resorted to really chopping some core requirements of the client and massively increased the product delivery time. But to what benefit? Two years down the line my client is going to want some lame radical change that is going to require if not a complete revamp, but more then 50% application change.

xeshu 2010-08-10 09:33:08

I wouldn't say they are standards for the poor man, but fundamental tried and tested design principles that have stood the test of time. A good designed system should be scalable. Sometimes you have to compromise, there are many documentated examples of when de-normalisation are your best option, but I still firmly beleive if you design the system properly it's going to be a lot more future proof than any other solution.

Tom Gullen 2010-08-10 09:39:08

I hear you completely! I have deployed a lot of projects, based on standard approaches and they blend in very well. Still running quite well. But I call these clients educated clients. Standards don't mean a thing to a lazy-client who does not know what he wants other then do everything on a single click of a button. I wish I could say 'no' and I know in software engineering, the programmer does have the right to say 'no', however some people disagree arguing that the client is still paying for it.

xeshu 2010-08-11 08:50:34

So when you cant say 'no' to this insane client request, you know for a fact that it will crash and burn as the years go on, would you go ahead and code it and invite your self into a maintenance nightmare or put your foot down (potentially losing the client)?

xeshu 2010-08-11 08:52:49

The client is the one paying you, and they are paying for your knowledge and experience. If they say to you, I want this application completed by the end of the day, you should probably let them know that yes, they can have it by the end of the day, but it's not going to be written in the most efficient way so it might lead to complications down the line. If you make them aware of the pros/cons of each option and they still want to go with the one which you consider worse, that's fine. When they come back angry 2 months later, just refer to your previous conversation with them!

Tom Gullen 2010-08-11 08:59:56

+1 A:

Well I think the ideal design is completely orthogonal, but you just have to accept that it rarely works out the way you envisage. If you've never read The Pragmatic Programmer, it talks a lot about future-proofing your code.

rmx 2010-08-09 15:04:05

Exactly my feelings. There is no such thing as a perfect design on a perfect application. And standards about design and code only go as far: they revolve around the client basically. If he is going to be a nightmare, there is no system in the world that will work for him. If he just wants a quick solution, no point in designing a rocket ship for him because he will not appreciate it and he will ask for radical changes. For those very few lucky people who do encounter those near-perfect clients, I envy them. :)

xeshu 2010-08-10 09:24:15

+3 A:

Personally, I would never set out designing any sort of app assuming it is going to be replaced within a few years. It is all to often those 'updates' and 'rewrites' get pushed off for quick fixes desired by customers who don't want to wait for an entire new application. Sure the requirements change, features are needed, but often they will be desired in the current iteration.

I mean, there are a lot of apps, languages, and design patterns out there that thought the same thing, and are still in use today. One that pops into my head is the y2k bug. Programmers in the 70's never thought their code would last 30 years, and surely someone would expand those year values to 4 numbers before the turn of the century. We all remember how that thinking turned out...

Kevin 2010-08-09 15:05:06

Your argument is valid and sound and I respect that. It depends on the type of project you are developing, and who the client is. For sure I would think about the project being deployed for 2-4 years but that is my maximum limit. I guess the clients I have worked for, I have completely lost faith in them.

xeshu 2010-08-10 09:19:16

+4 A:

I have worked at two different companies which had software products that were nearing 10+ years old. Although they had been extended with tons of new functionality and had been given many face-lifts, the core of the application was essentially untouched since the first stable release. This may not be typical, but if the architect is skilled enough, the system can be built to be modular and extensible enough to accommodate a surprising amount of growth.

acanaday 2010-08-09 15:09:22

Very true! Its down the the skills of architect. However what you are describing is a very pure environment where, the client is a little more educated then the average client. Since they have faith in the application now and they know it does the job, why change the core then. I wish more clients were like that, but unfortunately, with my experience of encountering various clients, that is not the case.

xeshu 2010-08-10 09:15:52

Well, no. These were two very distinct environments, one of which was an engineering/manufacturing environment which was about as far from "pure" as you can get. I suppose that it depends on the circumstances, but typically I don't think the client should KNOW when you are changing the core. That they do indicates a broken design, IMHO. They should merely provide requirements and receive new functionality in return.The other product was used by clients that were constantly evolving and extremely demanding! A well designed system makes managing difficult clients much easier!

acanaday 2010-08-10 14:55:49

The worst client is a client that does not know what he wants. Software companies using their experience try to give the client, based on his initial requirements (as you so rightly put) and deliver an end product (with client feed back and every thing). What would you do in a situation in which, the client, after 2 years of deployment says he does not like the way so-and-so is done, (which even though he is not aware of, but still is the core)? Would you say this is a bad program design? or an evil client?

xeshu 2010-08-11 08:39:26

I vote the latter, because no matter how good your analysis might be, if the client does not know what the heck they want, and want a system that does EVERYTHING on a click of a button, (lazy client), how would you respond to that other then utter frustration? I think that client would be PURE evil.

xeshu 2010-08-11 08:41:44

Much of the tech industry revolves around making things easy for lazy clients (i.e. doing things at the click of a button). If they're not requesting a *new* application, and you can't accommodate additional business logic, I call it bad design. If what they're requesting amounts to re-writing the core, I call it $$. If you're forced to rewrite the core of your system under unreasonable time constraints and you're not making a lot of money off of it, I call it poor business practice. In either case, the client is not evil. You've sold your own self into an unreasonable situation.

acanaday 2010-08-11 13:37:37

Its a bit of both. Clients don't want to put in $$$, they will always go for the easy option first of tweaking the code rather then a new build because it costs less however at the bigger cost of incoherent code (which they do NOT realise until we get a phone call from them). I would disagree on your point of bad design to accommodate additional business logic purely because if the client business models change radically, how can you accommodate that in a software?

xeshu 2010-08-12 08:37:23

In software, a design entity 'A' can only be made flexible enough to make it to 'A.1'-'A.9' BUT IT STILL WILL BE 'A' at the heart of it. You cant make an 'A' into a 'B'. But this radical core client requirement is asking for making 'A' into the 'B'. How on earth can your software accommodate that???

xeshu 2010-08-12 08:39:50

So, a core re-write is the only option and I agree with you the core needs to be flexible enough to handle insane radical changes, but at times clients go beyond that point where literally you just want to ripe their hearts out. I mean really, I am sure some of you programmers have had the same feeling at least at one point or another surely.

xeshu 2010-08-12 08:41:37

+2 A:

It really depends on the environment. I find that our internal corporate applications are fully overhauled (often retired) within 18 months of launch. It isn't anyone's fault - business priorities change, requirements change, new systems come online. At the same time other system run for a very long time.

We certainly don't develop any application with the expectation that it will soon be retired but there are business needs that need immediate solutions and sometimes it is better to get the app online and in the hands of the end-users as soon as possible. We update, iterate, and determine the next best steps.

Alison 2010-08-09 15:11:23

+1 A:

The data and data structures (often) need to be legitimately designed to last for decades. The algorithms, UI and everything else is expected to evolve rapidly.

If your data represents legal documents, financial records, you might be required to hold on to it for decades.

This, too, though can be taken to extremes. There are subsets of data that probably no one will care about in 50 years, like memory performance counters that might have been stored in the database.

MatthewMartin 2010-08-09 15:21:04

Financial applications, I Agree, last the longest among the pool of applications. However, still, I highly doubt they last more then 6-8 years. Data is preserved, no doubt. But other applications come in, or radical updates from the original application that basically is a revamp. So my point is, its not going to stay the same, change is inevitable. And the reason applications lasted for so long for some of you guys is because early 90's to early 2000's, platforms, frameworks, coding technologies did not change as often as they do now.

xeshu 2010-08-10 09:28:16

Its a fast paced world now, with the current mid-set of the 21st century client, I highly doubt applications would last even 5 years.

xeshu 2010-08-10 09:28:50

I've worked on code that used data structure from somewhere between the 50s and 80s-- the record layout was optimized for paper cards. I know people who were using financial analysis code around 2005 that was written in the early 1980s. In academia there is Fortran code still being used because no one is around smart enough to rewrite it. Even if the application is rewritten, often the legacy code get embedded in the new with just syntax changes. Anyhow, large organizations can only change so fast, regardless to the pace of innovation in the rest of the world. Depends on where you are.

MatthewMartin 2010-08-10 13:33:09

+1 A:

I remember a quote from James Kovac I believe, in one of the .Net Rocks' podcasts where he described our industry as:

one where the only constant is change

which is why you should design for flexibility so that when changes come, and it inevitably will in most cases* you will have an easier job adapting/updating your application. That's not to say you shouldn't try to build your application on solid grounds, but just more important to have a flexible solution which you can change easily than the perfect solution the first time around.

*I know in lots of banks people are still using ancient applications because it's too risky to change them and they simply don't have the expertise to change them anymore..

theburningmonk 2010-08-09 15:25:21

+1 A:

"The biggest roadblock to a great plan, is the dream of a perfect plan."

I agree - designing the perfect system which can be elegantly resilient to every possible future change, is fruitless. Every successful project is a tradeoff: building flexibility where you're confident it will be needed (or where it's easy to do anyway); and building somewhat quick-n-dirty code where you believe flexibility/change is unlikely. If you analyze the system well and the client has a good idea of their needs/requirements (not always a given), you'll get that balance right at least most of the time.

However, the idea that the whole system will be replaced every 3-5 years by some newer technology is also a fallacy. For every client who wants the latest, newest, sexiest system, there's 5 clients that are afraid to part with (or can't afford to replace) their legacy COM/VB/MS-Access/whatever system that is a morass of spaghetti logic built-up haphazardly without regard to maintainability, flexibility, or extensibility. You don't want to be the one building that system; if you are, then you're doing your client/employer a disservice.

mikemanne 2010-08-09 17:38:20

I agree with you whole heartedly 100%. However my experience of those legacy systems the client is running that has no regard for maintainability etc etc, is that at the end of the day, they want a new system. While true one of the main reasons is that the code was pretty much a nightmare to maintain, but that is NOT JUST THE reasons: Since its been so long, technologies have changed and blah blah, while they may not be able to afford the latest sexy application, they will be willing to settle for a mid-range product.

xeshu 2010-08-10 09:44:07

The point is: I design and develop applications as much flexible, extensible and maintainable as I can and if time permits. However, I know this same legacy system client that I now develop a new system for, regardless if its a messy code or the most flexible application ever built, will want a change. Why? Because he is now part of the 21st century. As I said in my other comments, legacy systems at that time lasted decades because the world was slow. Now a new framework is rolled out every 6 months. A new OS comes out every 2 years.

xeshu 2010-08-10 09:46:49

I wish clients had the attitude of "if it aint broke, why fix it!". But unfortunately, the 21st century clients are not like that. The ones with $$$ will want change NOW. The ones with moderate $$ will be okay to wait a little while. The ones who are broke will not care if the application is flexible or is full of haphazard half-@ss cooked up code. The point: The mind set that applications will run for ever needs to change. Two to four years is my best bet.

xeshu 2010-08-10 09:48:51

ansaurus

tags:

views:

answers:

Application design for 5 years

related questions