We had our first meet of the year http://www.meetup.com/Thessaloniki-Java-Meetup-Group/events/234154914/ of the Thessaloniki Java Meetup Group. BTW  I greatly enjoyed the talk. I always feel like a true weirdo when using multiline bash one-liners in my daily work:) . It was nice to see that I am not the only one doing that!

My thanks to Prof. Spinelis! @CoolSWEng

During the Q&A part of the talk one of our members, Dimitris Keramidas made a really interesting question that got me thinking. I have known many developers that have pondered upon this question – me included. If I remember correctly Prof. Spinellis had mentioned how we could use an automated testing infrastructure to help when debugging and in general how useful an automated testing culture is to the process of developing software. The question was something along the lines of the following:

Since testing is so useful, we who work in organizations that do not use it, how can we convince our manager, project manager, BA, bosses, stakeholders that doing testing is a useful thing and  convince them to adopt it in our work?

The response from the speaker was along the lines that writing software is a Developer’s responsibility and producing quality software is part of the professional ethics that must characterize her. Here he mentioned an example of how medical Doctors, when performing surgery they always count and test that they have all their tools accounted for before ending a surgery. It would be unthinkable regardless of the circumstances they wouldn’t do that.

He also mentioned that maybe our industry hasn’t matured  yet and offered how it has matured in the use of Version Control Systems where their use nowadays has become universal in contrast to the past.

I agree 100% and totally endorse both of these views but I believe there is also a more practical and realistic approach to advancing a testing culture.

The universal constant

The first idea that we absolutely need to embrace is that organizations and decision makers within them are driven by their business goals and ultimately everything that is done is about delivering business value.

Arguments that cannot be linked with business goals or value will have no effect. Arguing that it is cool, it is the current trend,  all the successful big guys are doing  it,  that it is the ‘right thing’ to do will have absolutely no affect in the long run. They might -emphasizing might- help you get the initial attention or help you get started but that’s about it.

As developers we have to argue with tangible and measurable evidence that our testing efforts advance the business goals and provide business value.

Does adopting testing when working on legacy systems provides business value?

There is the argument that Legacy systems that were constructed without any testing are unsalvageable and any effort geared towards testing will be wasted. I believe that we can reap the benefits of a testing culture even when this is the case.

I will share with you my personal experiences. Unfortunately for me, I haven’t been able to yet work in an organization with a strong testing culture but I have always tried to use automated testing in my day to day work as much as I could. And it has always allowed me to be able to work faster and create software that has much fewer problems/bugs. But the most important thing is that on many occasions it has allowed me to work on critical issues much faster, with greater confidence that I will not break something.

All of the above effects(faster development, less bugs, being able to better handle critical issues) can be documented and argued that they stem from adopting tests during development.

The chicken or the egg problem

Those that do not have experiense working day to day using testing will have one additional hurdle to overcome. As I said above they will have to present tangible evidence that adopting testing in day to day work provides business value. Which in turn means will have to be experienced enough to do that productively without affecting performance. But to gain the experience they will have to work on it and so on… presenting a chicken or the egg problem. To get one you need the other and vise versa. Unfortunately there is no sugar coating this. They will have to study and work on it on their own time. It would be ideal for  them, the organization be convinced adopting so it would be part of their work. But in this case it is they who wants to move forward and make progress and they will have to take charge of the situation. Obviously not having adopted already means that the decision makers are complacent and do not strive for change.

The caveat

Working on a legacy system and trying to introduce testing in day to day work comes with a caveat. Testing and unit testing in particular operate as a watch guard against a class of bad code that can creep into systems. Units [classes,methods] that are huge in size, do too much(many responsibilities), are very complex and have many complicated dependencies. It is a reality that when we have to work on existing code exhibiting the above code smells, it will be really really difficult and time consuming to write tests for our additions or changes.

Unfortunately we have to be really down to earth and accept the fact that progress will be slow.

It will also mean that we will also have to use common sense  and pass on opportunities to test functionality because overall it will be unproductive.

It is very likely that many will have experienced the following situations. A decree was issued that everything must be unit tested from now on. This led to no feature progress being done when developers spent most of their time trying to write and maintain complicated tests for complex code, and everyone becoming miserable as a result.

Handling strong opposition

Another problem that could be faced is an assumption that many people have: Working with testing is inherently slower for everything (and to be fair they are right for the cases discussed above when working in the caveat area).   These people would offer strong opposition to any use of any testing and they would even stop it because of deadlines, priorities etc.
What has worked for me in situations like this is that I did not openly discuss that I would be writing and using tests. At the point when someone would bring it up that I wrote unit tests I then could say: ‘Yes I did use them when working on feature X, but it did really well on production and our QA and customer are pretty happy with it. Tests were really crucial to this’. Remember the ‘universal constant’ mentioned above. If it provides business value or advances business goals it makes sense to do it.

I know of a case where the entire developer team who during the early stages of their project actually kept it very low profile that they were engaging in unit testing because they were afraid they would be reprimanded for writing two times the required code.

I am not saying here to be subversive and secretive. That would be counter productive in any team. But it is true that some times we have to take the initiative and provide concrete results and measurements to back what we are arguing about.

Conclusion

To sum up there is great potential from adopting an Automated Development Testing Culture in an organization. It can be a great tool to promote its business goals and add business value. To make this happen developers need to take the initiative and use it to reach these business goals and add value. This means that developers need to be very pragmatic in their approach taking small steps and always keep in mind that the ultimate goal is to improve productivity. This is  especially true when working on legacy systems containing a lot of non tested code that has the potential to become very difficult to test. They must also be very realistic and expect slow but in the end tangible progress. New features and modules will be easier to work with and with fewer bugs and in time even the old code through small or big refactorings will also become easier to work with.

Thanks for reading!