Jonathan Crossland
Posts: 630
Nickname: jonathanc
Registered: Feb, 2004
|
Jonathan Crossland is a software architect for Lucid Ocean Ltd
|
|
|
|
Future Proofing your Application
|
Posted: Mar 24, 2009 9:28 AM
|
|
Software lifespan types
- StaggeredRelease
We develop versions and patches and roll them out periodically.
- ContinuousLeak
We fix and create mini patches, live alteration, component replacement, live into the environment. Typically its developed by in-house staff, developers and/or support.
- OneHitWonder
An App created and used, more or less with no problems or errors. Seems to be around for a while, and then fades away. Typically a utility, which has very little value, and soon gets replaced or irrelevant. Typically a quick utility written by someone on inspiration, but with little time to spend on its up keep.
- RewriteEvolution
An App released again and again, but always with the knowledge that it will be rewritten and/or always seems to get rewritten. Typically where there seems to be little justification on spending a lot of time on it.
- ConcreteBeast
An App, that is not liked or really wanted at all, but seems to be impossible to get rid off as too many things are dependent on it. Typically a piece of software installed before you got there.
Future proofing can be expensive, but there are some easy things to do, to increase your odds by a few percentage points. So in order to future-proof it, what should you do?
First of all realize what kind of application its going to be, what characteristics will it have. You can use the quick list above, or some better scale.
Depending on less, not more
Loose coupling is an important factor in our making of agile software. Separating interface from implementation and other Patterns that promote loose coupling are very important for everyday development.
Use generalizations if you are not sure
Use a generalized, abstracted wrapper. Talk to your own Document object, and snap in with a Pattern of some sort, the actual real MS Word Document. This extensible model is vital, for allowing your Application to continue on through changes that happen around it. Actually this should be called use good Design Principles.
Control of Source and Components
Even though one tries to depend on less, we may still use many components, user interface controls and so on, which is good for reuse, but bad for dependencies. But try to avoid using reusable components, especially those you do not own, which is in direct conflict with increasing reuse and everything I stand for, but nevertheless.
Choose the right platform
Sometimes the platform or framework may dissipate. Choose your platform wisely. Think of Linq2SQL. Sometimes you need to go with something, like DAO, because, well, what else is there, that you could trust more? Now its ADO.NET which us currently 7? years old.
Know your RoadMaps
Get all the roadmaps of technologies that you depend on. Understand the manufacturer, their product cycles, and history.
Learn a lot, read a lot and get your intuition firing.
Ask your manufacturer
How long do you expect to support this component? How long? Its ok if its only 3 years, if it coincides with your application lifespan. Sometimes they can be very helpful, and sometimes you will find subtle aspects that will help your choice, so just ask.
Avoid the Latest thing
Unless, your intuition says otherwise. Its sometimes great being one of the bleeding edge, but its very risky.
Read: Future Proofing your Application
|
|
Previous Topic
