Our Blog

eCommerce
 
09
Nov 09

Developer Knowledge Sharing

The typical day of a software developer, like most workplace roles, is full of time pressures. You have to demonstrate that a particular piece of functionality behaves as per a user's story by the end of the week, and delivering late will impact the projects budget.

So you need to get it done, and move onto the next as soon as you can. When the project finishes, you move straight onto another. And that's not to mention the hundred possible day to day distractions.

The result is that day to day demands can easily distract the community of developers in your company from taking that important step back to consider the bigger picture, a vital ingredient in quality software development.

Without taking some time out to get all developers together for reflective consideration of processes and technologies you are using to deliver software, you can end up grinding away with the same familiar yet flawed or outdated methods, which make projects harder to deliver with the required quality and on time.

You can also end up with isolated project teams, unaware of what each other is doing - a novel solution to a problem may not be shared across all developers.

Projects should always end with a post-mortem. This usually involves everyone involved on the project: the PM, consultants, developers, testers, designers. Thus it is an invaluable project review, concerned with the successfulness of planning, meeting targets and deadlines, customer satisfaction, communication etc. However it is not a place for a developer code review, as it will be relatively non-technical, and only involves the subset of developers who worked on that project.

Therefore we need a different kind of review - a regular code review of a particular project (whether just started or long finished) or a technology, involving the entire development team. The goals should be:

  • To discuss and debate interesting, new or problematic processes and technologies, including everything from macro architecture to tiny code fragments.
  • To have as many developers as possible critically questioning why things were done as they are.
  • To highlight what code performed well, was easy to extend and maintain, and is easy to read and understand.
  • To highlight what code performed poorly, was hard to extend and maintain, and is difficult to read and understand.
  • To share software engineering tips, tricks and technologies across project teams, so everyone learns from other teams.
  • To share business knowledge across project teams, so everyone learns the business rules of new clients, what the solution does and how it benefits the client.

For example, in just a one hour session over some lunch to review a recently completed Windows Forms application, we covered the following topics:

  • AutoMapper, it's pros and cons, when to use it, problems encountered integrating it with Castle Windsor dependency injection container.
  • Accessing NHibernate entity collection properties (e.g. lists) - protection of a private instance, and exposing collection add and remove methods.
  • NHibernate configuration conventions.
  • Persisting 3 closely related entities in one database table using NHibernate, discriminating them using a table column. Pros and cons of this approach, how successful it was.
  • Managing database transactions in a Windows Forms application - use of conversation attributes, discussion of what application layer should be responsible.
  • Use of Behavior-Driven Design principles and rich domain objects, what effect this had on ease of development, readability and testing.

Topics like these are discussed day to day by developers within a team or between yourself and the person sitting next to you. The benefit of getting this discussion out into a larger debate involving all developers at the same time has been invaluable at Perfect Image.

James Allen

Filed under  //   automapper   bdd   development   knowledge sharing   nhibernate  
// 0 Comments