On Various Testing Levels

One of my very first few posts (dates end of 2008) dealt with the premise that One test level is not enough to reach a good qulity product. Then I argued on one hand that Integration tests are not enough, but on the other Unit tests are not enough as well. Only the Power of combining both approaches will truly help make your product successful.

Has anything changed since then?

Since then I had the chance to meet  a lot of great people who taught me a lot about Quality and specifically about testing. I had the chance to meet people like Lisa Crispin which exposed me to the Agile Testing Quadrants, Michael Bolton who taught me the difference between tests and checks and Elisabeth Hendrickson who really showed me that being a good tester takes a lot more than what I imagined.These people also helped me in refining and improving my understanding.
However I still think that relying on a single level of testing will not be an effective strategy.

Checked, Accepted and Explored

I think that I first heard this from Elisabeth Hendrickson:

Every feature (story) developed should be at least “Checked” “Accepted” and explored. Otherwise it is not Done

Checked

For most I use the unit test level to do this. Checked for me means that the code is doing what I think it does. Basically that it will exhibit no unexpected logical error and that the thing I intended it to do when I coded it is indeed what it does.

Accepted

For this I usually try to get as close as I can to E2E. Excluding the GUI. Accepted for me means that the system behave in a useful way. that is the user (or other person) that “ordered” the feature is indeed satisfied that the system behave in what he accept as a good way.

Explored

For this I use manual testing. Explored means that there was a person involved that played around with the system and tried to judge the general quality of the solution. usually there are specific question to answer in this phase, but sometimes this takes the form of free style testing. the goal of this stage is to use the brain power of a tester to see what else can be improved and whether or not the solution is indeed satisfactory.

Is that ALL?

Definitely not!
This is the bare minimum. In many contexts this is not enough. sometimes the system is just too big and needs testing at other levels, there are definitely the non functional requirements that need to be addressed and much more.
However this is a very good place to start. In some projects you can definitely achieve good enough results with only this. And if not, starting with here will give you a strong foundation to base the rest of your test efforts on.

The Twist

But what if were not in an agile context? Well the principles stay the same. I believe that using these 3 simple aspects even when you are not developing an end to end feature will do you good. Even when you are working in an team focusing on a horizontal layer of the product its just a matter of aligning your definition of what is the system under test. Each piece of functionality you deliver still needs to be checked accepted and explored. Its just that the accepted part takes a twist.
Since you are now working on part of the system, most likely your “customer” is not an end user but a fellow developer that needs to either integrate with you work or simply use it. However if you treat him like your customer he can still define his acceptance criteria. Most likely the resulting tests will be at the component (or subsystem) level and will not encompass the entire system. but either way the thing that you deliver will be checked, accepted and explored.

Read more »

Posted in: ATDD,AUT,Development Practices,Engineering Practices,Integration Tests,Unit Tests

“I have a Legacy System” is a lame excuse

Q: “why have you not written any automated unit test until now?”
A: “ look, we have a and complex big system. no one has written automated tests for it. it will take me too long to do it just now. I know its important but we have XXXXXXX so we cant do it now”
This kind of excuse, which sadly I hear way too often,  rate high among the “list of most lamest excuses”.
Don’t believe me?
How about this?
Q: “when are you going to cut down on your expanses and start saving money?”
A: “Look, I’ve already have a big mortgage on my house, and the cost of living has risen lately. So now is definitely not a good time to start saving. In fact since I just need to replace my car with a new one I’m just on my way to the bank to get an additional loan.”
or maybe this?
Q: “you know that you were diagnosed with high cholesterol, when are you going to start a healthy diet?”
A: ”you know you are right. But we are just entering the holiday season so now is not a very good time to start. In fact I cant wait for the family dinners, Health is not high on my family priorities, I’m guessing that’s why its so good”.
and this?
Q: “why aren’t you using a source control system?”
A: “well we have this big batch of code and its kind of a big mess. We thought about starting to use a source control, but it will take us too long to port our code into such a tool, and train all the developers. And you know we need to do XXXXXXX, so now is not really a good time”
Its Never too early to start
I think you got the point.
It all boils down to accumulating debt, technical debt in case of software development. That is,  you know you need to do something now. ASAP! But since  the effort involved seems to be high, you delay. You decide to take on additional debt, and with it comes additional interest. Causing you to do more rework and have less time and the monster feeds itself.
Face it, like most necessities in life there will never be the perfect time to do it. Test automation on all levels (unit,integration acceptance E2E,…) is not an option.  More and more teams realize that and do something about it. To stay competitive you will have to do it also, later will only make it harder. 
The fact that your system is big and complex is the real problem, Test Automation is one proven way to tackle that problem.

Read more »

Posted in: AUT,Development Practices,TDD

Starting TDD – One Day Experiment

A repeating question I encounter a lot is how to start with practicing TDD. in fact a while back I wrote a series of post on how one can start this in various contexts
(part 1, part 2, part 3, part 4, part 5, part 6, conclusions)
some people claim that TDD is a group activity, therefore it’s a waste of effort to practice alone. I believe that TDD is a personal skill, and while its better to have the whole team doing it, it can be practiced alone. Nothing should prevent you from trying to improve the quality of your code. (and in most cases the added value will negate any delays you might experience initially).
in this post I’m offering another way to start. in fact I think that a controlled experiment might be a better way to describe this. but anyway

Practicing TDD for 1 Day

To start you should dedicate a full day for this. while I'm sure this exercise can divided into several sections, I think that to truly benefit from this (and avoid the cost of context switching) it should be done in a single day.
By the end of the day I expect you to achieve the following:

1. have a good understanding of what TDD is and what are the rules to follow
2. write some basic unit tests on a simple problem
3. write a test case for your own system
4. have a basic understanding of the tools involved in the process.

I also expect that you wont achieve the following:

1. fully appreciate the costs and benefits of doing TDD
2. understand how to apply TDD in all situation
3. Be able to write tests to all parts of your system
4. have a deep understanding of Isolation techniques

(or put simply at the end of the day you will know some of the basics, but that’s about it)

Setup

in order to complete the day you will need to download and install some tools. specifically you will need a Testing Framework and a mocking framework.

Testing framework

any framework will do, really its not that important at this stage.

• .NET use MsTest or NUnit
• Java – JUnit
• c++ – GoogleTest

Mocking framework

pick one of the power tools available:

• .NET use Typemock Isolator or JustMock
• Java – PowerMock (you’ll need either EasyMock or Mockito in addition)
• c++ – Isolator++

(some of the tools are commercial so you will need to use their trial edition which is good for a few weeks)

Learning phase

The first step is to get a basic understanding of the principles involved. for this I would recommend the following session by Uncle Bob
Attempting as it might be don’t skip this part. It takes about an hour, but the important basics are in this. In order to succeed one must know what are the rules of the game and what are the expectations. doing TDD is not just about writing tests, its about how to write code differently. And the goal is to try this different way, not just write tests.

Do a Code Kata

pick a kata from the following page, any kata will do but I would recommend going with one of the katas in the Beginner++ section.
your goal in this step is to practice TDD on the kata.
that is apply the basic rules of TDD while trying to tackle a relatively simple problem.
I would expect you to be able to go through the kata (mostly) in under an hour

Learn Isolation Principles

The next step is to get familiar with your mocking framework of choice. Most likely, the easiest way to do it would be to go the the relevant tool website and get through the “getting started” or the “Introduction” parts. The goal is to understand what are mocking framework, what they are used for, and specifically learn the API of the tools and be able to use it.
If you want to invest a little more time and learn some of the theory behind this, here’s a very nice session (hour and a half) by J.B. Rainsberger which I personally like very much.
you should end this part by doing the following:

1. Create a new project.
2. To this project add 2 classes one that you want to test (Class A) and one which is used by Class A (Class B)
3. Add a method that just throw an exception to class B and make Class A invoke that method somewhere.
4. Next write a unit test which test Class A, specifically the part should activate the code in A that invokes the prepared method on class B.
5. Use the mocking framework in order to make this unit test work/pass.

Yes this is a very simple exercise, but in order to finish it you will need to pass through all the basic steps for using the mocking framework tool.

Take a break for lunch

Tackling the real system

The last part of the day is dedicated to write some unit test on your real life system. What we want to achieve is to actually write some tests on the real system that you actually works on.
The first step is to pick a place in the system to start in. The trick here is to chose an good part that on one hand wouldn’t be the hardest most complex part, but on the other hand still would surface the real issue that will be encountered later on. The ideal place should be a place that is focused on logic. Try not to go for upper part containing any GUI sections, and also try to avoid the lowest parts dealing with the data base (if there is one). If possible try to pick a class that reside somewhere in the middle tiers. hopefully somewhere inside the business logic.
After you picked your part, locate the class you actually want to write test for. When you have it, the first step is to locate the dependencies of the class you will need to handle. Start by writing those down on a piece of paper, and then dedicate some time to figure out how they are going to be isolated. Usually what helps is answering the following questions:

1. How are the dependent instances (the one used by the class under test) get created
2. How are they get “connected” (injected)into the class under test
3. what is the expected behavior you need in your tests

answering these question will help you later on in setting up the fakes (mocks) in your test.

Write some tests

next just write a couple of things you would like to test. The key here to start simple. think of a specific behaviors you want to test. for each behavior, think what is the initial state the test should start at, what is the action you want to test, and what is the expected behavior (result) of that action (and how you clean up after the test). When you have all those just try to write the test.
And always remember to have patient.
The first test in a new system is always the hardest to write. Even an experienced TDD’er is likely to take a couple of hours to actually get some tests on a new system. For a beginner it might take longer.

Summarize the day

Last action of the day is to think and reflect on the experiment. if you followed the steps, then you should have some tests on your real system. Now it is time to reflect on those and see what else you can learn. Think on all the things you accomplished during the day. Chart down the things that you need to invest more time in. Recap the main difficulties you encountered, and most important decide upon a few key actions you would like to take in order to continue your learning.
And of course let me know how it went.


Update
It seems that the kata site went permanently down so here some links to some code katas sites:

1. http://codekata.pragprog.com/
2. http://www.codekatas.org/
3. http://katas.softwarecraftsmanship.org/
4. http://content.codersdojo.org/code-kata-catalogue/

Read more »

Posted in: Agile practices,Development Practices,Self Improvment,TDD,tips

Starting TDD – Conclusion

How do I start TDD? is a question I’ve been asked too many times. Unlike many I don’t believe that in order to start you need the entire team approval. In this series I’ve described a few situation one might find himself in and offered some ideas on how to approach them. Although each developer has its own context i hope you can find some resemblance in the described cases and find the ideas useful. Since this is what I’m doing for a living this days, I would love to hear about your way on the TDD road and specifically on how you started and what were the initial experience.

last in a previous post i was asked by Daniel the following:

So if a single developer on a team is driving the design of his code by TDD, do you really think it would work? The code is probably going to be different in design hence other will probably have problems reading it since it could be a bit of paradigm shift. Also, if the TDD-developer has a similar skill-level as the rest of the members, the implementation time of each future will probably be longer for his items, even if the total time including corrections after QA-people, do you really think things like this will go unnoticed?

Daniel, I don’t know if it will work for you, but i have seen it to work several times. The differences in designs does tend to invoke a design discussion, which i have found to be a good discussion in which testable design is always defendable,in fact I encourage this discussion since they are a tool for winning people over. regarding your second question, I think that a reasonable developer (in many scenarios) can make the overhead nearly unseen, and i would also expect that it wont take too long for that developer skills to rise over his fellows programmers. However, I’m a believer of honesty and visibility, I wouldn’t try to hide what I was doing from anyone, and when challenged I would answer that this is the way i know how to code and point to the low defect rate resulting from doing things this way.

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (Part 6)

if you are really lucky you will find yourself joining an team which already practice TDD:

New developer joining a team doing TDD

You are just starting a new job (maybe in a new company). You have heard all about how the team is doing Agile (Scrum/XP) and how the tests are written before the code (TDD). In fact you are nervously waiting to start doing all those wonderful things.

Take a breath.

Joining such a team is not an easy switch. If this is your first time doing TDD (and Agile). It is going to be kind of a shock, working in an agile team is different in many aspects TDD is just one of them. It can take some time to make the needed adjustment. I myself have not fully experienced this, but helping other pass through the transition, I have learned that it can be a frustrating process, especially if you not a new developer.

The best way to speed the process is to make sure to pair a lot, i.e., Don’t work alone! Always ask to work along with somebody else on the team. Even if the team is not practicing pair programming on a usual base, insist that for your initial phases you would like to sit with others and learn how to do things properly. Pairing is a great way to get the needed knowledge and expertise (and the fastest way I know of).

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (Part 5)

With some luck, one day, the place you are working in will decide it want to fully adopt TDD. On that day you might find yourself in the following scenario:

A lone developer in charge of implementing TDD

The team/ manager have considered TDD, they chose to evaluate it and decided that its a good idea. the decision as made and in fact most of the team is quite happy with the change. However, since its a busy time they want to approach the subject with some care and have chosen you to start the ball rolling. that is you are expected to lead the transition for your team first by doing it yourself and then by helping the rest adopt the methodology.

The steps in this scenario are very similar to the one described in Part 4 the focus however is to gather as much real hands experience the fastest way possible.

Sometime this kind of experience can be bought. If possible, bring in an outside consultant that will help you in the transition. If not, try to to make sure the next hire has hands on experience.

if this options are not present, arrange for the whole team to attend some relevant gathering/conventions. Go with the team to TDD courses. and in any-case, when following the steps described in part 4 make sure to share and include other team members in the process. And last practice a lot of pair programming TDD session.

remember the idea is to share and include the rest of the teams even if they are not actively practicing TDD yet. A successful TDD adoption is much a matter of mode and spirit, not only a technical problem.

But always remember, The key factor is to gather as much hands on experience as possible and having the patience to build upon such expereince.

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (Part 4)

In some cases the idea of TDD is seen as a promising idea by the organization. lets consider the following

A Lone Developer in charge of evaluating TDD

You talked with your manager and thinks TDD might be a very good idea. in fact he has given you a green light to evaluate the approach. most likely other team members are also in favor of checking this out all are waiting for your conclusions.

In this context the plan of action is very similar to the previous scenario. The difference here is that you are expected to do a more thorough job, and you are expected to show result in a given timeframe.

Therefore, you still need to pass the learning phase, you also need to setup a CI Server and pick out the tools before starting. Time boxing the learning phase will be a good idea, while you still need to gain the knowledge you would like to do it as fast as possible, so pick the training solution that work fastest for you (for many a TDD course does a decent job in a short timeframe). On the other side you would like to invest more time in comparing and evaluating several options for your tool set (which include the CI product). at the end you will be find it easier to justify your choices if you can show that alternatives were considered.

Next step, is picking out a good place to start the actual writing. Since you are evaluating the approach, you probably have the option of picking out where you want to start, and the idea is to pick (for the first experiments) a place that you feel comfortable working on. a Place which will not be too hard. Try locating a small, decoupled section that is logic oriented. At this stage don’t try to tackle the most difficult place, there will be time for that as well. First gain some hands on experience with TDD.

Like initial stages, you would like to time box this first effort. When you finish it don’t forget to share your finding (and your difficulties). sharing along the way will help you when you finish the evaluation and a decision will need to be made.

According to the time allocated, you might have a chance to tackle a “tougher” piece with unit tests. If you are working on a legacy system now will be a good idea to approach the issues such a system present. You will need to gain more knowledge on refactoring and reading Michael Feathers book is also a very good idea at this point. Going through legacy code is harder and takes time. The trick to success with TDD is to have plenty of patience, this will become evident when working on legacy code. Getting help is also a good idea. If possible try using other team members via pairing sessions. Paring on the harder challenges is a great experience by itself and will also make the time for resolving the issues shorter. As a side effect you also introduce TDD to other in your team.

at the end always remember that you have a specific goal, to understand why TDD will be good for you and your team. And to show how it can be adopted by the rest of the team. So don’t wait for the time to end always remember to reflect on what the experience has thought you what were the benefits and what are the challenges. during the evaluation communicate with the rest of the team and draw them into the discussion. at the end you will probably need their weight to make the organization commit to TDD.

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (Part 3)

In the previous post I’ve talked how a even in the most hostile environment one can do things that will help on the road for becoming a better programmer. fortunately however the scenario described in the previous post is quite rare and in most cases things are not as bad.

The following is probably a more reasonable scenario

A lone Developer in an indifferent organization

You discussed TDD with your boss and while he is not against it, he doesn’t see enough value in it . Most likely his reaction went along the lines of:

Yes, automated unit tests are great but …

On the other side, you generally get enough freedom as long as you get the job done. other team members also think TDD an interesting concept, but again no one has yet made any move.

Start Learning

If you find yourself in this situation (which I believe is quite common), there’s much you can do. As always you start out by learning. Books, blogs, lectures, videos,.. anything will do. There is even a slight chance you can persuade your company to spend some money and sent you to an actual TDD course.

Setting up a CI server

Next step is setting up of a Continuous Integration server. Yes, I’m serious. If you are going to practice TDD, you should have a full blown CI server at your disposal. Setting one up takes somewhere between 30 minutes to a few hours. The benefits are huge, and down the line it will definitely help you convince others (most managers just love the visibility given by a CI server)

BTW You don’t need a dedicated machine for this. If you can’t locate a spare machine (and any machine will do) just set it up on your own personal development station.

Picking out the toolset

Next step will be to pick up the actual toolset for TDD. the most important thing about it is not to let this slow you done. While there are several options out there for every technology, for the most part the differences between the tools will have no affect at this point. Later on you might want to change the tools but even if that happens the actual cost of switching is usually minimal, and you will have much better understanding then. Just pick the tools you feel will be the fastest to learn. Don’t let the tools get in the way.

Practice TDD.

Now comes the fun part. Just start doing TDD. Pick up you next programming task and allocate some time for doing it the TDD way. If possible try to pick a standalone piece of code if not never mind. Don’t worry about doing mistakes. Don’t worry if your tests doesn’t seem like unit tests at all, and don’t worry if your are not following the TDD rules by the letter. You are just learning. And remember, in most cases it can take a couple of hours, maybe even half a day to write the first test. Things will become easier as you gather more practice.

You are not alone

Starting out TDD is hard. Without help it’s even harder. The fact that you are alone in your organization doing TDD doesn’t mean you shouldn’t have any. Reach out to the mailing lists. Luckily The web is filled with very nice people which likes to help. It might take some time but you will get the answers you need. The real trick for succeeding in TDD is just to have patience. It take some time to master a new skill.

Share you accomplishment

Hopefully after a few weeks/months you will be able to demonstrate the real benefits of TDD. If you stick to doing it, you will overcome the initial issues and will prepare the ground for the team to follow. You will have real experience, and it will be much easier to convince others of the value in TDD.

But even if not, if you got to this point you already are a better programmer.

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (Part 2)

In my previous post I explained that you don’t need the entire team in order to start TDD. So lets see some options for the lone programmer.

The question of where to start depends upon the context you find yourself in. For example lets consider the following:

A lone programmer in a hostile organization

You are a team member (or a team lead), you tried running TDD through the team but they feel its stupid, in fact they are strongly against it. If that’s not enough your manager also think TDD is a total waste of time and is closely monitoring to make sure you are focusing on writing production code only. And the worst thing is that the organization is a strict one, no tool can be used without going through the proper channels.

Yes this is as worst as it can get and there is not much you can do (other then maybe start refreshing your CV). But still you can start with the learning parts. TDD takes some knowledge to do properly, its not enough to just decide and jump ahead. there are practices to follow tools to be learned and techniques to be adopted. I have never encountered an organization that will block a determined programmer from acquiring knowledge, even if that knowledge is not directly related to current work.

Here are some places when TDD knowledge can be gathered:

Books:

1. The Art Of Unit Testing - Roy Osherove.
2. Test Driven Development: By Example – Kent Beck.
3. Working Effectively with Legacy Code – Michael Feathers.
4. Clean Code: A Handbook of Agile Software Craftsmanship – Robert C. Martin.

Mailing Lists:

1. TDD on Yahoo Groups
2. Extreme Programming on yahoo

Also there are numerous conventions and blogs dealing with TDD and other Agile Aspects. which deals with various aspects of agile development and some are even more specific to talking and helping with Conventions (and recording of)

It might also be a good idea to refresh on proper design principle and refactoring techniques as well. Even if you wont be able to practice TDD writing clean properly design code is always a good idea and i have yet to meet someone which object to that.

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (part 1)

One of the most common question I encounter is how to start with TDD. Usually the questions is formed as how do I get my team to pick up TDD.

There are many answers to this, and in fact it really depends on the specific context (more on this later) but one thing I do know.

You don’t need the entire team

A popular mistake is to think that a lone developer can’t do TDD and you need entire team do it together. This contradict the fact that TDD is a solitary practice i.e. you can do it all by yourself. Think about it, don’t you write code alone? TDD is a development methodology, its an exercise in producing high quality code, in that aspect its not different then doing low level design or writing clean code.

Do you need the rest of your team to design properly in order to produce good design (of your parts)?

Naturally the effect a single developer has is limited and will probably won’t go beyond his code, however doing TDD even if done alone will allow for his code to be better (and most likely faster). Of course its better to have the entire team do TDD. It’s usually easier and will increase quality of the entire product, but there is no reason to wait for everyone to realize that, is there?

So where to we start?

like always the answer is, “It depends…"

but more on this later

Read more »

Posted in: Agile practices,Development Practices,TDD

Integration Tests are not enough - Revisited

A while ago I wrote that Integration Tests are not enough (Part I). i Think that J. B. Rainsberger does the subject much more justice then in his latest session (Agile 2009) titled:

integration tests are a scam.

During his talk he also mentioned, as a side note, that what takes time and experience to master when doing TDD is the ability to "listen" to your tests and understand what they are telling you. I couldn't agree more, I wonder how we can help speed up this process.

Any thoughts?

Read more »

Posted in: Development Practices,Integration Tests,Self Improvment,TDD

Quality is infectious

In his recent post - Quality-Speed Tradeoff — You’re kidding yourself, Ron Jeffries has explained how high quality is mandatory in order to achieve high delivery rate.

There are many reasons for quality issues in a product, inherent technical complexity, lack of skill or just plain laziness. However an over looked factor that really hurt quality is pure pressure. When the pressure to deliver rises above a certain level (which vary for people and teams) the team starting to cut corners. When pressed developers will deliver. However we are not magic workers. When pressed we usually starts by working longer and harder, but when that's not enough, the only option left is to compromise current quality in the hope that part of the work can be delayed after the delivery. The mistake involved is the belief that after the release there will be time to fill in the blanks so to speak. naturally there is never enough time. In the agile community we even given those cut corners a glorified name, we call the work we should have done "Technical Debt".

Bad Quality is Infectious

The real problem is that bad quality is infectious by nature. It can starts by maybe skipping a needed refactoring, it might start by not writing  unit tests for a given component (assuming we will do it later) but very soon islands of low quality code start to form. As time goes by these islands have a tendency to grow. In a large enough code base they hide themselves for quite some time. They are always discovered at an inconvenient time when they affect work being done but when there is no time to actually fix it, so another workaround is coded, and again quality suffers just a little more. So they grow and grow until bigger problems starts to show, suddenly the escaped defect rate has significantly increased, adding new features become harder and takes longer. And quality continues to deteriorate until something is decided to be done about it. The problem is that by the time we reach the this stage the cost for fixing the issue is high.

Good quality is also infectious

The good news are that good quality is also infectious, most programmers (at least those I know) really want to do a good job and achieve a high quality code. So it doesn't take much effort to keep us on the high quality road. I have seen cases that a single team member by not compromising quality, cause the rest of the team to follow, even at points when pressure was high.

 

 

So the morale of the story is very simple, quality for me is mainly a state of mind. The moment I accepted the fact that by trading quality I always but always LOSE (and constantly reminding myself of this) I find it easier to achieve better quality. The up side is that I saw how this kind of approach infects others as well.

Read more »

Posted in: Development Practices,Random Thoughts

Cost of Change – The Fear Factor

Oren has blogged on how to reduce the cost of change. He claims and I agree that

Beyond anything else, it is the will of the team to accept the pain of making the change and actually doing this

When accepting this mind set its usually a lot easier to find ways of reduce the change cost . i.e. make it easier to change.

However I feel there’s another factor in equation, and that is the developer’s inherent fear of the unknown. Time and time again I’ve seen (and did that myself) programmers start implementing a change by attacking its easier parts first, leaving the real hard unknown issues to the end.

When adding a new functionality to an existing system for example, there are two main steps:

1. Implementing the new functionality.
2. Integrating it into the given system.

In most cases the harder part will be the second part, however 90% of the times a programmer natural instinct would be to start out with coding the new functionality.

As far as I could tell, the reason is that in most cases the new functionality is kind of a well defined problem, while the effect of the integration part is a big unknown, and most people will shy away from uncertainties leaving it to the end. and if we add to this the general “embedded”dislike of changing existing code (if it works don’t fix it) and we get the natural tendency to start with the well understood isolated new piece of code.

The problem is that in most cases the hard parts are, well, hard. They are the parts that will lead to the real problems which will take time to solve. Starting out with the easier parts of a problem leads to a false sense of progress which later on may bite when facing the real difficulties in the implementation.

Here's an example of such  a thing happening, in this case we have worked on a feature for quite some time, but were only able to complete it after starting all over again by attacking the hard integration issues first.

So don’t make the natural Mistake of letting fear of the unknown take over. Accept the fact that the hard problems are there and must be solved. and start by solving them first. When that’s done the easier parts will easily fall into place.

Read more »

Posted in: Development Practices,Random Thoughts