Strategies For Software Maintenance


Published on

Tips for software development agencies:
How to keep projects in good shape, developers motivated and clients happy.

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Strategies For Software Maintenance

  1. 1. Strategies for maintenance of custom development projects/software<br />31 January, 2010<br />
  2. 2. Who is thispresentationfor?<br />Agencies and customers involved in custom development software projects:<br />Software developers<br />Software architects<br />Project managers<br />Customers and stakeholders<br />It’s not a technical session, check out our other presentations for in-depth developer tips:<br />Working Effectively with Legacy Code<br />Unit testing”<br />31 January, 2010<br />Strategies for software maintenance<br />2<br />
  3. 3. Live or let die?<br />There are two basic strategies to maintain a software project:<br />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)<br />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.<br />29 January 2010<br />Working Effectively with Legacy Code (book review)<br />3<br />
  4. 4. Advantages of “keep it in good shape” strategy <br />Keep your project fresh: performs proactive, regular updates and technical maintenance in order to guarantee the best performance of your project. <br />This allows your customer to use the solutions longer and achieve a higher Return On Investment (ROI).<br />It keeps the developers happy and motivated<br />It creates returning income for the software agency<br />New features can be implemented faster and cleaner<br />31 January, 2010<br />Strategies for software maintenance<br />4<br />
  5. 5. Is the “let die” strategy always bad?<br />Not always.<br />Some software projects have a very short lifespan<br />For example something that will be used only once at a trade fair or presentation<br />Think twice before going the “let it die” route, once people like the software, you might want to re-use it.<br />Some customers simply don’t want to spend money to keep the project healthy.<br />31 January, 2010<br />Strategies for software maintenance<br />5<br />
  6. 6. How to keep software in “good shape”?<br />Train your developers to write good code<br />Give them enough time for maintenance work<br />Use good tools<br />31 January, 2010<br />Strategies for software maintenance<br />6<br />
  7. 7. Actions to keep software “in good shape”<br />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.<br />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.<br />Source Control: keeping the source-code database clean and well organized, automating builds and build server configuration, branching, ...<br />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, ...<br />Documentation: Writing of additional documentation to facilitate the on-going maintenance of the projects.<br />Lab environment: setup and maintenance of the internal servers used for testing and development of the projects. <br />Team communication: keeping the team members informed of the project status.<br />… and more<br />31 January, 2010<br />Strategies for software maintenance<br />7<br />
  8. 8. Communication & expectations<br />Make sure everyone is on the same page <br />Your whole team (architects, developers, project manager, customer) should understands what strategy we are using and what the implications are.<br />Most software projects require an important money investment. <br />If you choose the “let it die” strategy, make sure your customer fully understands the implications.<br />It is typically the task of the project manager to<br />Explain the customer about good software maintenance concepts<br />Convince the customer to allocate an ongoing budget to keep the project healthy<br />31 January, 2010<br />Strategies for software maintenance<br />8<br />
  9. 9. Developers: be careful! <br />Don’t start refactoring before talking with your PM/customer<br />If you do, you will be in a world of pain, since:<br />Your time will not be appreciated/paid<br />Problems/bugs caused by the changes will be taken badly<br />Make sure there is a clear agreement of the time you can spend on a monthly/yearly basis for refactoring/improvements.<br />This time should be budgeted in the yearly maintenance agreement with the customer<br />The dev-team should have the flexibility to use this time at the moment they feel it’s mostly needed.<br />29 January 2010<br />Working Effectively with Legacy Code (book review)<br />9<br />
  10. 10. Commonmistakes<br />Situation<br />The customer does not even now what “refactoring” mean<br />The project manager heard about it but does not calculate it in his price offerings<br />Developers complain because the code is turning into spaghetti.<br />Action<br />Developers start to do refactoring without approval, resulting in time that cannot be invoiced and new bugs<br />Customer complains about bugs and missed deadlines <br />Project manager tries to solve a situation that he could have avoided in the first place.<br />31 January, 2010<br />Strategies for software maintenance<br />10<br />
  11. 11. Service agreement / maintenance contract<br />If you choose the “keep it healthy” strategy, make sure you have a solid maintenance agreement with your customer.<br />As a software agency, your service contract should cover the 3 basic types of work:<br />Maintenance: monthly/annual budget to keep the project healthy.<br />Time & material: for smaller requests. Time spent it charged according to timesheets.<br />Fixed-price: for larger, well defined projects. Software agency commits to a fixed price for the development, according to detailed project specifications.<br />29 January 2010<br />Working Effectively with Legacy Code (book review)<br />11<br />
  12. 12. Maintenance: bothProactive and reactive<br />A good service contract should cover both reactive as proactive tasks.<br />Reactive<br />Recovery of defects / fixing bugs<br />Third line helpdesk<br />Proactive<br />Technical evolution: upgrades, OS, patches,<br />Transferability to third parties: by writing good documentation, clear backups and data recovery/system transfer guides.<br />Less time spent on future features and bugfixes: by doing refactoring/unit tests, etc<br />Internal organization of software partner: by doing internal meetings, knowledge transfer, keeping source-control, build scripts, etc.<br />29 January 2010<br />Working Effectively with Legacy Code (book review)<br />12<br />
  13. 13. 13<br />Strategies for software maintenance<br />31 January, 2010<br />