Real experience of adding first sets of Tests to existing code base

I recently joined a team of very skilled and talented people. We wanted to put in Tests for an application which was running in production for quite some time. I cannot specify the details of the project but it had tens of thousands of line of code in it. It was developed in Microsoft Dot Net and SQL Server and a web application.

I would like to share some insight and recommendations:

  1. Long running tests and writing long dependency tests setups is the norm
  2. Adding technical debts in tests will be needed but keep it as clean as possible.
  3. Don’t worry of Unit Tests in the beginning. It will be lot harder to do it.(Add Integration tests, refactor code in smaller units, add unit tests later)
  4. Some types of test that will help you during this initial testing phase :
    1. Pinning Tests : http://c2.com/cgi/wiki?PinningTests
    2. Characterization Test : http://c2.com/cgi/wiki?CharacterizationTest

You must be thinking you already know all this stuff above. But the view point I want to share here is some real world numbers and facts. Firstly add  a automated code coverage to get the results of your tests with just one click. (a simple .bat file worked for me)

  1. I was working with the code for first time.
  2. It took me 16 hours to put in first 6 tests.
  3. These where clean, re factored and commit ready to Git.
  4. Code Coverage was 6% after 6 tests.
  5. When I added 5 more tests the code coverage was 15%
  6. Tests were covering different classes of different modules.

This stats may be controversial and its true that code coverage doesn’t signify that your code has 100% automated tests for all possible scenarios, However here are some reasons to go with it.

  1. It give some numbers to go for during initial stage of adding tests.
  2. It will help you to add test harness for different areas of applications.
  3. You can share reports with team and get feedback on what’s next.

Happy Coding!

Advertisements

Agile Manifesto over a decade

It has been over a decade few developers got together and coined a name “Agile“. It was definitely a developer centric software development methodology. I am a novice to speak any further about agile movement. I saw different version of Agile manifesto over the past years, I listed 10 of them here.

  1. The Original :http://agilemanifesto.org/
  2. Kent Beck version : He was one of the person in the initial signatory of Agile manifesto. He gave one for Lean Start up read it here.
  3. Uncle Bob’s lead version: He was also one of the person in the initial signatory of Agile manifesto. It was a part of Software Craftsmanship movement : http://manifesto.softwarecraftsmanship.org/
  4. Agile Scout : They are people who practice agile. This was written as a retrospection after 10 years of Agile movement, read it here.

Let see some opposite views of Agile. I don’t know them so won’t give any brief about them :

  1. Dark Manifesto: http://darkagilemanifesto.org/
  2. Anti Agile: http://antiagilemanifesto.com/
  3. Half arsed: http://www.halfarsedagilemanifesto.org/
  4. Programming M*****F*****(bad language BIG NO, I am sorry to add a link with this language however he has a point): Obfuscated Url 

And to end up here are few Enterprise version for Agile

  1. IBM : A version by one of the IBM consultant, read it here.
  2. Enterprise : A version by a guy called David, read it here.

I hope you take a full advantage of Agile and consider it as another tool in your tool box.

Get started! Write code.

In Indian software world from where I come, we mostly work as vendors to the clients. Challenges we have as talked with Siddesh, on how client’s expectation is very high, ambiguous requirements and sharp deadlines, it might sound all too familiar in any part of the world.

Since Indian software clients are growing and maturing, it will be very important to experiment and spike with different solutions to see what works mutually with the client and the software team working with them.

Here is my take on it. It is just an personal opinion and there will be many arguments against it. But here is my point of view. The first primary challenge is to get confirmation if the contract is with us or not. But as soon as you get in touch with any technical details, start creating a spike. A version of spike’s meaning can be found here. You may argue that how can we start writing code without complete analysis. I am talking here about non production code.

Listen to this discussion on a idea of Test Driven Development between Jim Coplien and Robert C Martin in YouTube. They talk about writing production code of a telecom application (app size 2 million lines of code). They need half an hour to start writing the code. I think we can definitely write up some code to get a better understanding about requirement and gain some confidence.

At organization level, we can have repositories of all such spikes so that in future we spend less time in creating those. Such situation could arise for example when we end up giving the project to other teams with in the organization or if the project goes on hold. We will always have working executable code as our knowledge base. Thus, we will have information on the uncertainty of the requirement + the existing knowledge of business as usual. It is easy in theory then actually doing it. But that’s the challenge.

Happy Experimenting!

Pair programming Dojo Experience

I and my friend did a Dojo last month you can find it here. Below are the experience we had.

Gautam’s learning:

  1. How much the experiences of the 2 developers worked in different environments differ from one another. His way of coding, ways of finding & implementing solutions etc.
  2. Working with Vikram also forced myself to think of different ways to prove my point and to keep patients when there is discussion on a particular topic (Specially when we discussed about the starting point of the tests execution.)
  3. As far as coding is concerned I learn few shortcuts from tools and learned a better technique of renaming variables and functions which I knew how to do it but never thought of implementing not sure why.
  4. Above all I did my first TDD during this Dojo so got to learn a lot about it. Also learned about how keep your excitement in control while implementing various functionalists while working with TDD.
  5. Overall it was a small session of about 2 hours but we learned a lot from each other and looking forward to continue this Dojo.

My learning:

  1. How a solution approach is different of a person for instance: Gautam was insisting to add few more test cases to make sure the code is working were as I wanted to follow the rules that was instructed.
  2. The names of methods came lot better with 2 pairs of eyes.
  3. When we pair up with new individual how we must slow our self and the fellow member while learning new skills. Patience is the key.
  4. Learned a handful of key shortcuts which was a normal habit for the fellow member
  5. Adapting to work with new laptop with some of the keys placed totally difference from mine.

Even though most of our experience are alike, but adding it explicitly made a lot more sense of understanding.

Happy Pairing!

Android Apps for software developers

Here is a list of three apps I frequently make use during/for my software development activity.

3 Android apps I use are :

  1. Stack Overflow
  2. Pomodoro
  3. Twitter

Stack Overflow : It doesn’t need any introduction. If you really care about your craft try to contribute to the community. Answer the questions out there in a more human way possible. When I am not in front of my computer. I just have to see it on the app with the notification coming on the top. Thus letting know any progress in my previously answered or edited question. It helps to keep the score.

Pomodoro : Its is a time management technique. A very simple one but not easy to practice. In crisp it helps you to focus on a task for 25 minutes. Its a timer that goes of every 25 mins followed with a 5 minute break called as Pomodoro time. The apps give you a sticky note to write down your current task. The main challenge here is to focus on your working during those 25 minutes. Initially you can make a list of distractions during the Pomodoro time. Later have action plan to overcome the distraction. Find details on Pomodoro Technique.

Twitter : WHAT!! Yes you must be wondering how on earth can twitter help you become a better developer? But really if you use the tool effectively it is really helpful. It can play a role of aggregator of information. You can select people whom you want to follow, be it technical, leadership, personal development or entrepreneur. Make sure that they don’t spam your tweet feed. Also remember you can always un follow people. Go through your tweet feed when you are waiting for something. The wasted time could be converted into learning. And yes you can follow me @vikramshettyc

Also share your list of Android app on your mobile phone.

Happy learning!!!

Beautiful Code

The code which is understandable, maintainable, robust, decoupled and neat can be called as beautiful code. Many may definitely argue with me, for the justification of the definition. The bigger questions here is not what the definition of Beautiful Code, it’s about how do we learn to take our code in direction of Beautiful Code.

A simple human nature is when we understand a concept we embrace it without conflict. For instance every programmer understands conditional “if“. So when it is in your code you don’t feel alienated but when you find it spread all over the code block you feel so frustrated. We may conclude a stage of beautiful code looks like, code must be easy to understand and easy to change. See I mentioned the word easy.

Here are few tactics to sharpen our skills, understand our code and embrace to change.

  1. Learn & Practice Test Driven Development period
  2. Create the written one page goal of beautiful code standard your team considers to be good enough. Thus creating clarity in achievable goal.
  3. Make a list of coding style changes you want to see in your teams code e.g: No single letter variable or Code should read like English. Compile a list of 10 items. You can use any method to conclude but make sure everyone contributes to the list.
  4. Learn new technical skills every week. This could be as simple as using a keyboard shortcuts, implementing new language feature, or implementing design patterns. The key is that it must go into production code. Make it a part of daily routine.
  5. Give a small token of appreciation on daily achivements thus creating a growth culture. It could be as simple as clapping in a stand up meeting for a team member.

Happy Coding!

Go Code Refactoring

Code refactoring is must have skills in our tool box.

Wikipedia gives below mentioned definition

Code refactoring is the process of restructuring existing computer code without changing its external behavior.

There is a classic book on Refactoring by Martin Fowler.

The topic is vast when there is a whole book written. I am trying to mention 3 easy steps we took in our recent project to get started:

  1. Renaming variables and method names. In all the modern IDE there is a feature of renaming the variables and method names. It’s safe because it will not break your compilation and still guarantee your code will be read better. The code is better from the time you do your first rename.
  2. Delete all commented code. It is self-explanatory. An excuse given is I may need the code in future. You can get your code back by using source control system, So use source control system to archive your code. Thus reducing the lines of code you don’t have to browse through your code at all.
  3. Extract method is one of the handy ways when your method starts growing huge. If we us the help of modern IDE it has the feature to do it safely. We have to be careful but IDE will help us in a great extent. This technique will also help in reading your code better.

Happy Refactoring!