Only Software matters

Experiences in software development

Archive for May, 2011

To Sonar or Not to Sonar ?

Posted by Patroklos Papapetrou on May 19, 2011


To Sonar or not to Sonar?

This is the first question that a project/product manager, team leader, software department director, customer, developer, ui designer, architect, tester or whatever role/title exists in a development team should answer. This is not a simple question about using an additional quality tool to help you with software development by providing some statistics. I suppose we all have plenty of them installed. This is not a simple question to see how much you care about the total lines of code and their test coverage or to find which classes have the most violations. There is no competition and no prize about that! It is the only question that you ought to answer in order to show how much you care, how much you REALLY care about the overall quality of your software. If you already use Sonar, then you should probably already know the answer and feel free to read our experience. On the other hand if you have never used Sonar or even heard about it, then this is your chance to find out how this little (but great) piece of software have changed our lives (as developers) and enhance our products.

I am an employee of a relatively small software development company, located in Thessaloniki, Northern Greece. There are about 25 developers currently working in small teams. The last 1 ½ years I am in charge of a team composed by 8 members. We are responsible for the maintenance of 5-6 systems (products) and in the meanwhile we have completed a project for one of our customers. Currently we are working on two new products. Since last May (2010) we are using Sonar and here is my little fairy tale about it.

Can I describe our development life before Sonar with a simple word? Of course I can!! Darkness. We had no idea of the situation in our code. We run no unit tests. We did not know whether the design and architecture of our systems allowed significant additions of new features or important changes, which made us very apprehensive about any refactoring attempt. Violations; Security flaws; what the heck are these? Duplicate Code? God bless copy – paste. Analyzability, Testability, Stability, Changeability were terms we believed that we needed to look-up in a Chinese dictionary to find out their meaning. Bugs were discovered late in the development lifecycle causing some red-alert situations and releases seemed to be some kind of middle-age dragons that our support and test department had to fight before they come out to our customers. And then some kind of a miracle happened. I cannot remember how I reached Sonar website, but right now I am quite sure that, those 10 minutes needed to read some of Sonar features, changed my development life.

Without any second thought I downloaded it and in a couple of minutes it was installed in my personal computer. Full of excitement I configured it to be integrated with Maven and Jenkins (Hudson at that time) and after a couple of minutes I was starring at my screen in front of my first ever Sonar analysis. I admit that my initial feeling was an extreme disappointment regarding the quality of our existent product but as soon as I realized the possibilities of this unknown to me software tool, I was absolutely stimulated about our new life. Immediately I showed it to my team, shortly explaining them, the different metrics and what do they mean about our project, about the QUALITY of our software. A new era has begun. Today, almost one year later, Sonar tracks all our projects through nightly builds – analysis. Every morning the whole team checks the project dashboard, and the differential views, especially from last analysis, and from last stable version. We have configured thresholds for the metrics we count the most, so whenever a build is out of the accepted limits, it is broken. We handle these builds just like all broken builds. It is our first priority to fix a sonar-broken build and to restore the required quality. Before we begin a refactoring task we always study our Sonar analysis related metrics to find out signs of poor design or architecture. We continuously strive to be focused on every aspect of software quality from the first day of the project and without any doubt; Sonar is the best ally we could ever hard. My favorite views are Treemap and motion Chart? I love to see my bubbles changing colors and moving towards perfection. I love to see my tree getting green from red. With a single view I can figure out which components need our further attention. It’s easy! Just pick up the red big-ones and start cleaning up your code!!

Our new product releases are much more stable. From dragons are transformed to butterflies. Trust and confidence in our team has significantly grown. We feel no fear when we have to add some new functionality or modify existing features. In other words, this is our Sonar life! The new version, 2.8, is already out there and I cannot wait to try some of its new features like quality profile comparison and manual reviews. I would be also very happy if we could purchase the SQALE plugin. Come on Sonar guys I am sure you can do a better pricing for this kind of plugins.

I can’t imagine my development life without Sonar. Ι sometimes wonder how we and our code could “breathe” some months ago. Sonar gave us the missing oxygen. I have answered my question to myself. I have chosen light instead of darkness. it’s your turn now!

Advertisements

Posted in quality, sonar | 6 Comments »

Get Your Customers On Board – Continuous Feedback with Demos

Posted by Patroklos Papapetrou on May 14, 2011


Introduction
Most of us,during the development of a software system, have probably received some major changes requests from customers near the end of the project. Even worse, during a demo session, the end users as soon as see (for the first time) the final(?) product jump out of the window screaming and cursing you and your team:”This is not what I wanted. I don’t like it. Get it back and bring me something else”. What exactly is this “something else”? No one is able to explain it and at this point of the project being under budget/time pressures it is something extremely difficult to clarify. With a simple (greek) word: A CATASTROPHE. If you find your self smiling at this moment then at some time in the past you have been in such a position and of course, for that we usually blame this unsatisfied and indecisive creature that we call “the customer”. No matter how many times you have tried to “freeze” the requirements in the early stages of the project either because you had a fixed-price contract, or because “we need to know in advance what we are going to develop”, the only thing you achieve is to “lose” the customer from the beginning of the project and obviously, this is not what you would expect. So, are we really unprotected against to our customers? Of course not. Our purpose is, or at least should be, the delivery of a system that covers as many as possible, and always within budget, customer business needs. One of the agile practices I like and I believe that help towards this aim is the one i simply present (for agile dummies) in this blog.

Some simple rules and guidelines

Frequent demos for immediate feedback are extremely imporant and come to fill the gap between the development team (what is implemented) and end users (what they really want from the system).The fact that from the early stages of the project, the customer  participate at regular intervals in such meetings, ensure that critical requirement changes and misunderstandings are identified as soon as possible. Thus the implementation cost is far lower than the scenario where the same change is “discovered” much later when the project would be in advance.As for each agile practice, however, frequent demos should follow some rules and guidelines in order to get the maximum of the. The following brief instructions are  mainly focusing to projects where there is a single customer.

  • Since the beginning of the project, therefore, describe in details the practice you intend to follow and try to explain its return of investment. Make clear that these demos have a single purpose. To understand early in the project what are the actual needs of end users and get as soon as possible feedback on the track you follow, so if something is extremely wrong you have adequate time to fix it.
  • If there is some kind of dissatisfaction about the large number of releases, it is good to clarify that these are not real releases, but internal demos, which will be not available to all users. There are nevertheless valuable for the early diagnosis of requirements misunderstandings.
  • Respect customers’ free time. Try to find an approach that will make everyone happy. If the customer can not attend a demo at the end of each iteration (for example every two or three weeks) try to make it at the end of each month. This, IMHO, is the maximum allowed period between two demos.
  • Try to ensure that you really have to show something. New features, modified or redesigned screens are essential in a demo and should work with no problems. If the customer is frustrated by a non-working demo, then it is most likely that he loses confidence in the development team and distrusts any attempt for future meetings.
  • The demo should be done only by development-team members so that he/she will show the customer features that need his/her attention and feedback. Do not let the customer “play” with the release. Politely remind him the purpose of this meeting and that the demo version of the system is not suitable yet for beta testing.
  • Remember to make clear before each demo that the product/system is still under development and that this is NOT what the end users will get. Try to focus on core and critical business requirements so you can get important feedback, but this does not mean that you ignore proposals for the usability, the user interface, etc.

Product vs Project

What happens though, when we do not have a single customer, but our product is targeting thousands of customers? Obviously, the frequent demo aproach seems to be unrealistic or it may be applied to a limited extent. For that reason, I propose below a couple of alternative actions that will replace this practice aiming at the same results (get early feedback).
  • Try to create videos that demonstrate the new feature of the upcoming release- several days before its official announcement. Something like a pre-release announcement.The main advantage of this approach is that with minimum cost, we can briefly show (the duration of the video should not exceed 2-3 minutes), the core features for that we would like to get feedback and comments from our customers, before the new version is actually released
  • Try to provide a try-it-live demo site where customers (existing and potential) are allowed to test the new upcoming version (Beta versions, Release Candidate versions) and send with a predefined way comments and feedback.
  • Try to gather some of the customers (if they are located in some or nearby places) or a webinar for long distance-customers and perform a demo session instead. Although this will not have the same results as if you would showing the product in a single customer, but you may get some important feedback.
Benefits
Some of the practice’s benefits are summarized right below:
  • Early detection of misunderstood requirements.
  • Correction of the project “path” at a very low cost.
  • Continuous communication with the customer.
  • Increase confidence between the development team and end users.
  • Creative collaboration to achieve the same purpose (meaningful and working product)
  • Most critical and core features are delivered first and complete without having to reach at the latest phases of the project.
Probably the above list is not completed, so if you have some more ideas (remember this post is for agile beginners and not experienced users) feel free to post your comments.

Posted in agile, demo, feedback, frequent | Leave a Comment »

My first opensource journey

Posted by Patroklos Papapetrou on May 6, 2011


A few weeks ago, without any particular reason, probably to satisfy my continuous research for new hobbies and interests, I decided to contribute to an open-source project, initially developing a small plugin (module). The truth is that I did not take under consideration what I might encounter during this effort. Now, having completed the first version of the plugin, I feel that I finished a short journey in a different world of software development from that than I knew, and with this post I would like to share my experiences. Before that, however, I believe that it is appropriate to shortly describe what the plugin is about.

For over a year I am using the (in my humble opinion) ultimate tool for software quality which is Sonar. What makes Sonar so perfect and amazing? The infinite possibilities that offers to a software team in order to monitor the quality of a project under development / maintenance in detail. it covers the 7 axes of code quality: Design and Architecture, Duplicate Code, Unit Tests , complexity, potential software defects, Comments, and finally code rules.Integration with other popular systems like Maven as build system, and Jenkins for Continuous Integration practices, definetely increase its capabilities. Of course, to be honest, to benefit from Sonar, it is not enough just to keep track of code quality, but rather to act continuously towards improvement. The plugin, therefore, I developed for the Sonar, provides integration with Google Calendar, which is part of the suite of applications offered free by Google. Whenever Sonar completes the analysis a quality project, the plugin takes action and creates an event in Google Calendar set by the end user.
What did I encounter during my first opensource try?
Firstly I found a very structured and well-organized environment/community that provides tools for rapid development of plugins, control them, test their usage by other developers (SNAPSHOT release) and final publish them to thousands of Sonar users. The developers, are always willing to contribute their knowledge, ideas and comments whether positive or negative. There are rules and procedures, strictly followed by everyone, that define how the code is developed, how the documentation is written, about automated build processes and quality ( eat your Own Food ), even how much spaces should have the pom.xml file that describe the plugin. At almost every step there were a sonar core developer who was correcting me (thank you Evgeny!) and was giving extrelemely valuable feedback. I confess that after fifteen years of experience (?) In software development I felt like a student who developed my first Hello World example! Even how and when a plugin is ready for release is determined by a voting process among active developers/contributors of the project. All so different from what I was used or learned so far and so exciting for someone who wants to work within a standardized environment.
What have I learned – How have I expanded my technical knowledge?
I extended my knowledge around Maven. I learned new features in practice and how they serve specific purposes during the development of a (sub) system.
I studied a working example of a modular system without the cumbersome use of other technologies like OSGI. Besides, I used it to develope, test and release the plugin!!
I discovered the new google-api-client and more specifically the part that needs to process data in google calendar. A completely different API, and an approach that only … Google could ever follow!
Finally I participated in a community of developers with different skills and knowledge, but they all respect each other and exchange ideas and comments without hesitation and intolerance.

My feelings
Initially, enthusiasm, which was then replaced by deep speculation until I managed to understand both systems and their API (Sonar/Google Calendar). With the completion of a beta release I started receiving feedback. That was a grear disappointment but make me try even harder for the final result. New efforts for better quality , always attached to the prescribed rules and procedures.Finally the first version is ready. It is approved by developers community and to be honest I feel as proud as I felt when I was finishing some lab exercises back in the mid-90s ?

For one thing I am absolutely sure … The open source software community of Sonar won one more supporter and as my free time permits I will continue to contrinute to it!

P.S. More Info about the plugin can be found here

Posted in calendar, google, open, plugin, sonar, source | Leave a Comment »

 
%d bloggers like this: