So then what should you look at? After a bit of head scratching and navel contemplating I came to the following conclusions.So obviously the code / system needs to be scalable, correct (no bugs), complete (delivers what is needed), extendability (it can grow organically) and well documented, but ultimately it will probably live for a long time and will be worked on by many people so… drum roll please…It needs to be easy to maintain and of good quality (have unit tests etc).

What is good code then?

I feel good code is code that “everyone” feels they understand. It is easy to change, add to and re-factor. It should be as simple as possible (but no simpler) and should be as loosely coupled to other systems as possible.

Why should we write good code?

Well the simple fact is that usually many people work on the code over the lifecycle of a system. People leave, get hit by a bus, move on, go to jail etc and someone else needs to maintain what is left behind. The most maintenance programmers either want to completely rewrite all aspects they touch or they are too terrified to touch anything so they bolt bits on the side of programs because it is just too complex to maintain. Both of these scenario’s are bad for everyone involved. Ideally if we approached every project with the spirit of “Ubuntu” i.e. we code for the people that follow us (egoless), things would be a lot better in the long run. Also, if we built quality in right from the start (by using things like Test Driven Design – TDD) it would make the life of people making changes to the code much easier since they have a suite of tests to run that will make them more confidant about making changes (the tests should catch any foul ups or unconsidered side effects)

Lately we have been doing a lot of code audits for firms. This involves looking at the software process from a number of angles.This includes the following:

• Architecture and design
• • We usually look for the following aspects
  • • Scalability
    • Integration points and methods
    • Flexibility
    • Performance and monitoring
    • Database layout and schema
• Code quality
• • Follows coding style
  • Commented and “JavaDoc”ed
  • Simple as possible design
  • Patterns implemented
• Documentation
• • Architecture documentation (UML, Context diagram,etc.)
  • Specification of some sort
  • Technical specification
  • Non-functional requirements (load, performance,etc..)
• Testing
• • Unit tests
  • Load tests
  • Performance testing and monitoring
• Change control processes
• • Source control implemented
  • Processes around change management
  • Continuous build environment
  • Issue management process

We have been applying service orientation to help organizations consistently deliver sustainable business value, with increased agility and cost effectiveness, in line with changing business needs.

Through our work we have come to prioritize:

• Business value over technical strategy
• Strategic goals over project-specific benefits
• Intrinsic interoperability over custom integration
• Shared services over specific-purpose implementations
• Flexibility over optimization
• Evolutionary refinement over pursuit of initial perfection

That is, while we value the items on the right, we value the items on the left more.

Guiding Principles

We follow these principles:

Interesting presentation – watch out for the catch ….

Microsoft designs iPod packaging