, , , , , , , , ,

Capri sponsoring Agile Manchester 2015

AgileManc_FullLogo_Colour_RGB_2015Capri Consulting are proud to announce their sponsorship of the Agile Manchester 2015 taking place in Manchester on 7 and 8 May 2015.  Whether you are new to Agile  or have more experience there is lots of interesting content for you with great speakers like Liz Keogh and Jurgen Appelo and 25 sessions, it’s going to be a productive 2 days!

We are very excited for the event to take place, as it is set to be a corner stone of the Agile industry for 2015. It is particularly exciting as Agile has been becoming more and more popular in recent years, with more and more companies adopting the Agile Methodology, of which we are advocates. Book your place now, as tickets are selling fast


Make sure you come and check out the Capri Consulting stand and collect freebies! See you in Manchester!!

, , , ,


Recently overheard heated debate on code refactoring. I felt they were mixing up refactoring with rework and agile model was being blamed for not designing upfront therefore need for code refactoring. This resulted in waste of time, organically grown-poorly-commented-complex- code that needed retesting.

So, why and when do I refactor my code?

Simple answer is, when you are sure that you will never ever have to touch a piece of code again, there’s no need to re-factor that code.

But most of the time, you will have to touch it again because you will have to add features, fix bugs or optimize it.

  1. To eliminate/reduce the “Code Smells”
  2. Easier for any developer to understand the code
  3. To make it maintainable.
  4. To increase cohesion and to reduce coupling”

I don’t usually recommend refactoring just to reduce code smells, or make it ‘nicer’/more maintainable. I do suggest you refactor your code, when you need to fix bug, and you want to leave code in better shape than it was before. Other reason is when you want to add functionality, and it would be hard to do without refactoring. Third reason is to make code more testable. Sometimes refactoring will help you to learn the code which you don’t understand 🙂

Refactoring is used to pay your Technical Debt. Code refactoring is a necessity of observing the fact that change is inevitable. It’s principal goal is to enhance the current code or design in order to make it amenable and congruent with new functional or non-functional requirements or to make it more tolerant to change.

Examples of scenarios where refactoring may be necessary:

• Introduction of a new business rule that requires the current design to be abstracted to a new level;
• Recognition of the fact that the current design could be modified in order to better observe the SOLID principals of object-oriented design;
• When code testability needs to be increased—this relates to 2 above.

While you are refactoring
• Avoid code duplication when I see it (following DRY principle-need to write a blog on this too)
• Simplify the code (remove unnecessary ad-hoc complexities, KISS- keep it simple and stupid)
• Remove old/stale/deprecated code (cleaning waste, once the old code is replaced)
• Eliminate side effects
• Generalize and reuse existing code
• Reducing complexity of individual functions – makes testing easier
• Eliminating repeated code – reduces opportunities for mistakes

And finally, Its not waste of anybody’s time!!!!