2. Who is thispresentationfor? Agencies and customers involved in custom development software projects: Software developers Software architects Project managers Customers and stakeholders It’s not a technical session, check out our other presentations for in-depth developer tips: Working Effectively with Legacy Code Unit testing” 31 January, 2010 Strategies for software maintenance 2
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 2010 Working Effectively with Legacy Code (book review) 3
4. 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 motivated It creates returning income for the software agency New features can be implemented faster and cleaner 31 January, 2010 Strategies for software maintenance 4
5. 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 maintenance 5
6. How to keep software in “good shape”? Train your developers to write good code Give them enough time for maintenance work Use good tools 31 January, 2010 Strategies for software maintenance 6
7. 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 maintenance 7
8. 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 to Explain the customer about good software maintenance concepts Convince the customer to allocate an ongoing budget to keep the project healthy 31 January, 2010 Strategies for software maintenance 8
9. Developers: be careful! Don’t start refactoring before talking with your PM/customer If 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 Working Effectively with Legacy Code (book review) 9
10. Commonmistakes Situation The customer does not even now what “refactoring” mean The 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 Strategies for software maintenance 10
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 2010 Working Effectively with Legacy Code (book review) 11
12. Maintenance: bothProactive and reactive A good service contract should cover both reactive as proactive tasks. Reactive Recovery of defects / fixing bugs Third line helpdesk Proactive Technical 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 2010 Working Effectively with Legacy Code (book review) 12