21 September 2009

Best practices in brownfield development

The wikipedia definition for the term 'brownfield is this : ''In the United States city planning jargon, brownfield land (or simply a brownfield) is land previously used for industrial purposes or certain commercial uses. The land may be contaminated by low concentrations of hazardous waste or pollution, and has the potential to be reused once it is cleaned up. Land that is more severely contaminated and has high concentrations of hazardous waste or pollution, such as a Superfund site, does not fall under the brownfield classification. Mothballed brownfields are properties which the owners are not willing to transfer or put to productive reuse.[2]' .

I couldn't agreed more with this definition, especially about the hazardous waste and pollution parts. Brownfield development in software industry is very common, rarely a developer will develop a system from scratch without dealing with legacy code and applications.

In my opinion brownfield development is hard, and understudied. Every book on software development teaches how to develop a green field project, e.g. a project developed from scratch. Which is good. But no one is taught the essential skills and practices of brownfield development.

And that hurts. Very much.

What are the problems associated with brownfield development? They are many and varied and depend on both technical and human reasons:

  • Lack of understanding on the underlying reasons why a technical solution was chooses to solve a particular problem.

  • Lack of any legacy technical documentation and tests.

  • Developers think they know the 'only right way' to develop software.

  • Fear and uncertainty of breaking existing, working functionality.

When working on brownfield project I've found the following to be true and very helpful and productive:

Do not try to re-engineering the project when implementing new functionality, when the time comes that will be the only thing you will be doing. That way your will not bog down on useless, defect prone work.

  • Do it as the other guy, use the same existing infrastructure and follow the same development principles. That way you will not add competing solutions and will achieve a homogeneous environment.

  • Write a short, concise documentation for each feature you develop. That way everybody will know what you have done and why.

  • Document key technical solution and practices in the project. Some problems and questions keep reappearing over and over. That way you will save everyone the time and effort of figuring them by them selves.

  • Write smoke tests (functional or unit) for the core functionality of the project. That way you will always know if the core works or not.

The goal here is to not increase needlessly the complexity of the system, to save time and effort and to quickly gain the core knowledge the other guys had. If the client wanted you to re-engineer their system they would have hired you for that specific goal. It is often better to follow existing practices and procedures than to try to reinvent the wheel and fall in a bottomless pit of defects keeping popping up and deadlines never met.

10 September 2009

Another day sprint

I'm concluding another day and a half development sprint. I started yesterday at five a.m. with a trip to Zagreb which lasted till six p.m. , filled with back to back blood grinding meetings. I've returned to Labin at eleven p.m. and started working on a deadline pressed project with three other developer. We've succesfully deployed the newest application version fifteen minutes ago. Another hour, and I'm crashing and burning into the nearest bed.

What lessons I've learned:

  1. Writing at least functional, or just smoke, tests solves much development problems

  2. Task development is half of well done feature

  3. Regular standup meetings for tracking progresss and quick reactions to changes in the project situation

  4. Wokrin in a virtual enviroment saves time and money, and increases the speed a new developer can join an undergoing project

  5. Power naps help a lot

What is the motivation for doing a day and a half development sprint? For me is the challenge and the opportunity to be a hero, to save the day. To complete something hard and critical, which not many people can do. For others, I don't know exactly, but I recon is the same as me. I feel downright special right now.

Well I am special. so are my colleagues, we are a special team which completed something special. Nobody can take that away from us.