Developing software ain’t easy.
How do you know how you are doing ?
You could start collecting metrics about your code. These can give you some indication how maintainable and reliable it is.
The metric which come to mind to the most people is code coverage. Some people say it must be near 100%, other say 80% is a good number. At the end it can’t tell you if you are doing great or good. The only thing you might read from it is that a low number indicates a potential problem.
Duplication is another one you should look out for. A high number of duplicated code might bring up the problem that a bug was fixed in one place but lives on in other. If you are doing code generation (e.g. from WSDL’s) you might have a lot of duplicated code reported to you. A closer inspection is needed to really make sure this is a problem in the code you have written and is not auto generated.
Test success is not a metric you should be worried to much about. It just needs to be 100% at every checking in a shared repository. No discussion.
Cyclomatic complexity let’s you measure the number of linearly independent paths through your code. A high number means a more complex code. A complex code base is hard to maintain and involves a lot of work to adopt it to new requirements.
Dependencies between packages is another important value to check on (see Uncle Bob’s paper on Acyclic Dependency Principle). Basically it revolves around that packages should not have cyclic dependencies between them since this does have an impact on releasing and testing (and therefore coding). A change in one package could trigger a whole system build to make sure everything works together.
Tools like Findbugs let you define rules to which your code should comply to. This is great because it is tailored to your code/company and ensures you control and fine tune the measures. Or so. It requires some time to define these rules. They need to be refined over time and you have to understand them to make use of it. Of course you can leave out some of these and reduce complexity. Do not underestimate the effort to implement these.
This rounds up the metrics you can get from your code base.
But wait, there is more.
A valuable metric is the meantime between reporting a feature or bug and fixing. This gives your team (and management of course) a rough estimate how fast you can react to market changes.
To get an estimate of the mean time before a failure happens you can measure the time between two bugs. The higher the number the better. Current reported bugs per lines of code can also be measured. These metrics will give you some confidence in your code base.
At the end of the day the ultimate measure is the money on the company’s bank account. If this is not working out you are in trouble.
How to get all of these ?
There are some static code analysis tools to get you started. I only can talk about Java related tools but there are others as well.
To get more information about your bugs should query your bug tracking system like Jira or Bugzilla.
Summary
There are much more numbers out there but I think these are the ones you should always keep an eye on.
Look out for
- Code Coverage
- Duplication
- Cyclomatic complexity
- Cyclic dependencies
- Test success
- Time to market
- Mean time between failure
What metrics do you look out for ? Let me know in in the comments and why.
Whenever you create an object you have to find a meaningful name.
While renaming later in modern IDE’s is no problem at all you should not pick the first name which comes to your mind.
Imagine you have an external fraud detection web service and it will return a ‘hit’ or ‘miss’. How do you name this object? HitOrMiss maybe (since this is the representation you get from the webservice) ? It might describe the problem at hand. If you go with this name it will dripple down through all layers. The domain model, the dto’s, services and more will now reference to this object (and create their own derivates for it). Your colleagues which code up other parts of the system will refer to it and create their own variants of the name (like structure for web pages). The wrong name is now all over your code.
So much for refactoring in your IDE. You will never catch all the places automatically where the wrong name was used.
While it seemed lost time discussing the ‘right’ name for 5 minutes in the beginning it saves you much more time afterwards. Of course you might get also confused a couple of weeks later remembering what this thing really does and what it is used for.
Make sure you take time in naming your objects. A wrong decision can do some harm to your code. The later it turns out that the name was not correct the much more expensive it becomes to correct this mistake. If you are not really sure how to name it, talk to your colleagues and discuss the name. A second opinion can not hurt.
Maybe FraudDetectionResult would have been a better choice.
© Mrs Logic @ flickr
One year ago I started to blog again. Time for a little recap.
Why did I do it ?
I use this blog to write down my own thoughts about software and development. This is for my own reference but also it is a little way to give something back to the world wide community in return for all the useful stuff I do read on the net.
I noticed how this also made me a better programmer. Try it out by yourself. Having a professional blog is also a good way for Personal branding.
Stats for the last 12 months
I love number so here they are:
About 15.000 unique visitors
About 20.000 pageviews
Traffic
20.64 % Direct Traffic
36.34 % Referring Sites
42.44 % Search Engines
Highest page views on one day: the Selenium 2 post, 620 pageviews (ok, this was big link of the day at dzone.com).
Countries
I had visitors from 120 countries.
3362 visitors from United States
2090 visitors from Germany
776 visitors from United Kingdom
Top posts
GeoLocation with HTML5 2670 pageviews
JSF 2 and maven 2607 pageviews
Selenium 2 and Concordion vs. Cucumber each 1566 pageviews
I have 142 RSS subscribed readers.
All in all, not too shaby 
.
Thanks
Thanks to everybody for reading my thoughts. Thanks for the comments and hints.
I’m looking forward to the next year. It is going to be a great one.
