strategies for software maintenance
DESCRIPTION
Tips for software development agencies: How to keep projects in good shape, developers motivated and clients happy.TRANSCRIPT
Raas van Gaverestraat 83B-9000 GENT, BELGIUM E-mail [email protected] Website www.orbitone.com
Tel. +32 9 330 15 00VAT BE 456.457.353Bank 442-7059001-50 (KBC)
www.orbitone.com
Olivier Mangelschots Strategies for maintenance of custom development projects/software31 January, 2010
Strategies for software maintenance2
Who is this presentation for?
Agencies and customers involved in custom development software projects:
Software developersSoftware architectsProject managersCustomers and stakeholders
It’s not a technical session, check out our other presentations for in-depth developer tips:
Working Effectively with Legacy CodeUnit testing”
31 January, 2010
3
Live or let die?
There are two basic strategies to maintain a software project:Keep it in good shape: by doing regular maintenance work such as refactoring, documentation, unit-testing, etc. The software can have a long lifespan (5+ years)
Let it die: just add code on top of the existing. After a while, it will become impossible to add new features and fix bugs without loosing massive amounts of time and money. At a certain point, it will be better to start all over.
29 January 2010Working Effectively with Legacy Code (book review)
Strategies for software maintenance4
Advantages of “keep it in good shape” strategy
Keep your project fresh: performs proactive, regular updates and technical maintenance in order to guarantee the best performance of your project.
This allows your customer to use the solutions longer and achieve a higher Return On Investment (ROI).
It keeps the developers happy and motivatedIt creates returning income for the software agencyNew features can be implemented faster and cleaner
31 January, 2010
Strategies for software maintenance5
Is the “let die” strategy always bad?
Not always.Some software projects have a very short lifespan
For example something that will be used only once at a trade fair or presentation
Think twice before going the “let it die” route, once people like the software, you might want to re-use it.
Some customers simply don’t want to spend money to keep the project healthy.
31 January, 2010
Strategies for software maintenance6
How to keep software in “good shape”?
Train your developers to write good codeGive them enough time for maintenance workUse good tools
31 January, 2010
Strategies for software maintenance7
Actions to keep software “in good shape”
Code Refactoring: Improve the program code readability, simplify code structure, change code to adhere to a given programming paradigm, improve maintainability, improve performance, or improve extensibility.
Unit Testing: The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. It avoids bugs when changes are made in the software.
Source Control: keeping the source-code database clean and well organized, automating builds and build server configuration, branching, ...
Updates: Software updates and security patches that require specific testing or modifications to the projects described above. For example: .NET framework updates, Visual Studio project updates, new browser versions, ...
Documentation: Writing of additional documentation to facilitate the on-going maintenance of the projects.
Lab environment: setup and maintenance of the internal servers used for testing and development of the projects.
Team communication: keeping the team members informed of the project status.
… and more
31 January, 2010
Strategies for software maintenance8
Communication & expectations
Make sure everyone is on the same page Your whole team (architects, developers, project manager, customer) should understands what strategy we are using and what the implications are.
Most software projects require an important money investment. If you choose the “let it die” strategy, make sure your customer fully understands the implications.
It is typically the task of the project manager toExplain the customer about good software maintenance conceptsConvince the customer to allocate an ongoing budget to keep the project healthy
31 January, 2010
Working Effectively with Legacy Code (book review)9
Developers: be careful!
Don’t start refactoring before talking with your PM/customerIf you do, you will be in a world of pain, since:
•Your time will not be appreciated/paid•Problems/bugs caused by the changes will be taken badly
Make sure there is a clear agreement of the time you can spend on a monthly/yearly basis for refactoring/improvements.
This time should be budgeted in the yearly maintenance agreement with the customer
The dev-team should have the flexibility to use this time at the moment they feel it’s mostly needed.
29 January 2010
Strategies for software maintenance10
Common mistakes
SituationThe customer does not even now what “refactoring” meanThe project manager heard about it but does not calculate it in his price offerings
Developers complain because the code is turning into spaghetti.Action
Developers start to do refactoring without approval, resulting in time that cannot be invoiced and new bugs
Customer complains about bugs and missed deadlines Project manager tries to solve a situation that he could have avoided in the first place.
31 January, 2010
11
Service agreement / maintenance contract
If you choose the “keep it healthy” strategy, make sure you have a solid maintenance agreement with your customer.
As a software agency, your service contract should cover the 3 basic types of work:
Maintenance: monthly/annual budget to keep the project healthy.Time & material: for smaller requests. Time spent it charged according to timesheets.
Fixed-price: for larger, well defined projects. Software agency commits to a fixed price for the development, according to detailed project specifications.
29 January 2010Working Effectively with Legacy Code (book review)
12
Maintenance: both Proactive and reactive
A good service contract should cover both reactive as proactive tasks.
ReactiveRecovery of defects / fixing bugsThird line helpdesk
ProactiveTechnical evolution: upgrades, OS, patches,Transferability to third parties: by writing good documentation, clear backups and data recovery/system transfer guides.
Less time spent on future features and bugfixes: by doing refactoring/unit tests, etc
Internal organization of software partner: by doing internal meetings, knowledge transfer, keeping source-control, build scripts, etc.
29 January 2010Working Effectively with Legacy Code (book review)
