Wednesday, August 15, 2012

Code Metrics Viewer extension for Visual Studio

If you're a manager or team lead, metrics are probably a regular part of your work day. How's the Sprint going? What does our project burndown look like? Do I have enough money left in the budget this quarter for the toolkit the team just requested? How many pizzas do I need to order for the Planning meeting?

I hope you're looking at metrics on your team's software code just about as often as you look at those numbers. One tool that's helped me to do that very efficiently is the Code Metrics Viewer extension for Visual Studio.

So what kind of metrics does this tool collect for you? As the author of the tool puts it, he endeavors to measure "evolvability of a software system, which is an indicator of the inner quality of software". Seems like it would be a good idea to keep an eye on that! Code Metrics Viewer makes this visible through five categories, which I'll briefly explain (technical explanations are available through the links):
  1. Maintainablity Index - In my opinion, this is the most important metric per class. It is a weighted calculation of the other metrics listed below; consider it as the "overall" rating. A score of 20 indicates reasonably maintainable code. However, I suggest you look for at least double that number if not more. The last two major projects I ran (both multi-tenant web applications) averaged a score of 79 across all assemblies. [1]
  2. Cyclomatic Complexity -The number of possible paths through the code, generally determined by logic blocks (IF .. THEN; FOR EACH; DO .. WHILE; SWITCH .. CASE). To me, this is probably a close second in terms of importance; think of this as the number of test cases (read: team cycles) that might be required to properly cover all the possible results / outcomes of the module. 1 is the lowest score; keep this number as low as your business needs allow.
  3. Class Coupling -A count of the number of other classes Class ABC depends on. Look for a score below 25.
  4. Depth of Inheritance- How many other classes are used to make up this class? The more there are, the tougher it can be to follow the flow of the program when modifying or debugging. A score around 3 here is good; above 6 is a warning.
  5. Lines of Code - pretty simple; how many lines of code are in the class.
This tool is easy to install and use - simply download it and double-click to install. The plugin page I linked to above also contains information on how to run an Analysis on your Solution; read the "How to get it working?" and "Where can I find the Code Metrics Viewer in Visual Studio?" sections on that page and you should be all set. The author has also set up a blog to share some additional tips and tricks for the tool.

If you don't have a metrics tool for your .NET projects, I suggest giving this one a try.

[1] - I ran into an odd situation while writing this article that I need to investigate further. I ran the Metrics Viewer on a small Solution that creates an .exe file. Even though the three main classes, which made up 80% of the codebase, only averaged a 56 Maintainability Index rating, the Solution received an 80. I think this is because there were some very small classes / enums that scored 90-100. My initial assumption is that the overall Maintainability Index rating is an average of all the class-level ratings, and is not weighted like the class-level ratings. In my case, this was confusing, as I had most of my major classes showing the yellow warning signals, but still received a high rating on the whole assembly. I will try to clarify this with the author.

UPDATE (11/27/2012): I had some extra time off over Thanksgiving weekend and was finally able to reach out to the author, Matthias, with my question. Matthias was very helpful; he confirmed my thought that the Overall Maintainability Index is in fact an average of the Maintainability Index ratings for each class, and shared the following information:
"... the formula to calculate the maintainability index for the module ... is correct ... but again, I would not give that much into that single value. The maintainability index is of course a magic number, which demands some quality feeling when working with it ... Whenever I do reviews based on metrics I use the maintainability index as some kind of pre-filter criterion to unveil the hot-spots, but afterwards I take a look at all numbers (even LoC) to detect code smell ... I am not sure if the maintainability index is good enough to express how clean and evolvable a software system is."
He also said he has started work on a similar plugin for Visual Studio 2012, but ran into an impediment; the Professional version now includes a very similar feature.

My thanks to Matthias for his time in answering my questions, providing some guidance on the tool, and for building and sharing it in the first place.

Tuesday, August 7, 2012

Resource: Brad's Sure Guide to SQL Server Maintenance Plans

On a few occasions, I've been asked to fill in as a temporary or emergency DBA for periods of time, usually during or after a company transition of some kind. While I am by no means an expert DBA, I can keep things running smoothly for a few months, thanks in part to this little ebook - Brad's Sure Guide to SQL Server Maintenance Plans.

Neither of the environments where I assumed this role had Maintenance Plans when I started - at least beyond the Full Backups. After doing some reading online, I was fairly convinced that implementing a more thorough Maintenance Plan regimen was a best practice that we should have been doing for a while - I just wasn't quite sure how to get started.

I distinctly remember thinking this book was going to be exactly what I needed after reading the following two segments: Brad's creds on page xiii (obviously very experienced with the subject matter), and his introduction for the book on page 14:
"In many cases, organizations have SQL Server instances that are maintained by a part-time DBA, or an "accidental DBA," who may be a network administrator, developer, accountant, or even an office clerk. In the worst cases, nobody is looking after the health of the SQL Servers. ... with the guidance I hope to provide in this book, [SQL Maintenance Plans] can become powerful tools in helping the "accidental DBA" to perform critical maintenance tasks, and so help to ensure SQL Server's performance and availability. In addition to learning how to use these tools you will, along the way, pick up a lot of good, general advice on SQL Server database maintenance."
Sweet! Sounded like he had written it just for me!

So why should you take time to read this book and follow the advice within? Why are Maintenance Plans important to your SQL Server environment? I'll let Brad explain:
"The goal of implementing [database maintenance plans] is to help prevent [all] kinds of problems ... If implemented correctly, [maintenance plans] can help ensure that a SQL Server's databases perform adequately and, if there should be a problem, provide the necessary backups to minimize the loss of any data. Another benefit of implementing a database maintenance plan is that it helps to prevent, or to catch early, many different kinds of database-related problems. By being proactive with a good maintenance plan, time spent troubleshooting problems after the fact is often reduced."
The first 4 chapters (about 80 pages) give an excellent overview of the basics of Maintenance Plans and how they work. Subsequent chapters go on to explain why you should or might want to consider implementing a certain type of Maintenance Plan, and how to do it. The "why" portion of each chapter was very valuable to me as a non-expert, and really helped me narrow down what I needed to implement (or avoid) to make improvements in my environments. The Database Mail configuration portion alone (Chapter 2) is a great process walk through. I had to do this for both of the environments I was working with, and probably would have spent a bunch of time on Google trying to piece together the correct steps from a plethora of articles.

One of the things I really liked about the book is that Brad takes the time to specifically explain all of the settings - with screenshots - and why or why not to use them. As you read it, you'll understand why this is valuable - not all of the fields mean what you think they'd mean. As an example, on page 181 while discussing the Cleanup Task, he states:
"The last option is to specify the age of the files beyond which they will be removed, using the Delete files based on the age of the file at task run time option ... This is another tricky option. First of all, don't deselect this option. If you do, the Maintenance Plan Wizard will assume that you want to delete all instances of the specified type of file, no matter how old they are. Of course, this is not what you will want to do. You will only want to delete files that are over a particular age."
I also appreciated how the book is organized. It's not the kind of book you'd probably sit down and read cover to cover, and the structure reflects that well - it's a quick reference resource that you can easily go back to whenever you need to set up a new Plan. It's really easy to jump to the details on a specific Task and quickly get all the information you need to set it up or modify it.

There were just a couple of slight issues I ran into while following the examples:
  • He states early in the book on page 16 that all of his screenshots (of which there are many) are from SQL Server 2008. As I was working with SQL Server 2005 in both cases, there were some differences for me in what he was describing. Overall though, almost everything worked as he explained it.
  • Brad recommends setting up just a few Maintenance Plans with multiple Tasks, but I ended up having to create separate Plans for most major/daily tasks. This was because my maintenance windows were not large enough where I could pack multiple steps into a single Plan. Again, his instructions worked beautifully, it just took me a little longer to create the 7-8 Plans I needed.

In short, I highly recommend this resource, particularly if you find yourself in a situation like I did.You can get the book from Brad McGehee's site using the link I provided in the first paragraph.

Wednesday, August 1, 2012

Intro - sharing what I've learned about the business and craft of software

Why start a blog? And a blog about making software no less? Wordpress estimates that they alone have over 54 million blogs online and actively maintained right now while I'm writing this.

So why make another one? Isn't it just noise at this point? Am I really going to put forth ideas and solutions that haven't already been covered by all these other writers ad nausea?

I'll share a story.

At my very first programming job, I was fortunate to work with a great consultant named Steve. Even though he wasn't a software developer by trade, I learned a lot about making software from him. One of things I liked best about working with him was that just about every time he came to the office, he brought a new tool with him. A spreadsheet that was all set up and ready to go for tracking / documenting a specific task, a batch file with a couple lines of code for moving our files around; whatever it was, it usually made my job easier.

He never charged for them either; it was "just part of working with him" he'd say. As a consultant, he worked with a lot of people in other parts of the country programming on the same system, and used this opportunity to build small tools like these that would be useful to everyone, and then shared them as part of his visits.

I always appreciated Steve's approach in sharing the things he learned, and my intent for this blog - and to address the opening question, the reason for starting it - is to emulate him in that regard. While I'm not the most renowned expert in any area, I have learned a lot about the business and craft of software over the last 10 years. I hope that the stories, resources and tools I've collected over that time and going forward will be useful and interesting to others, and that they have the same effect Steve's tools had for me. This blog is just a place for me to share what I've learned, and hopefully to help a few people make better software.

NOTE: Steve is still sharing his knowledge with Shop Floor Experts. My thanks to him for teaching me the right way to do things at a very early point in my career.