Browsing all articles in Agile
Dec
16
Comments

Agile Demos Smells

imageThere are many things that I look at when I see a demo, one of thing that fascinates me are demo smells. These are automatic actions that developers do when the demo doesn’t quite go well that underlay conceptual problems.

For example when seeing a demo at the end of an iteration, does the developer have some script that he keeps running from time to time, does the developer delete files when something wrong happens, is the process monitor running. Looking at these actions gives great insight into the potential architectural bugs.

If there is a batch file, there might be some kind of environment problem, if files are being deleted there might be some integrity problem, if the process monitor is up there might be a process synchronization problem.

It is normally cheaper in the long run to solve the root problems and save time when running the application then to keep performing these automatic actions.

Ask about these actions, you will get surprising answers! Then see what can be done to remove these actions.

May
6
Comments

Unacceptable: Unit testing will take 20 years to catch on

Author Eli Lopian    Category Agile, Unit Tests     Tags

During the Typemock Partnership Academy Panel in Oslo, I had a very strange feeling coming from Uncle Bob, when asked “what is the state of unit testing” that was the feeling of acceptance, but I felt a tingle of consent perhaps a bite of giving in.

image
“We are on track, everything is ok, the state of unit testing – is the state of unit testing, so their is no place to feel happy or sad about it” and “it will take 20 years, and that is ok, most of us, the ‘bad’ developers will die out and be replaced by craftsmen”

Gil Zilberfeld although quiet, nicely pointed out: “I feel like I am listening to a Buddha Guru”

I feel very different, I know that 90% of the developers don’t unit test. That is 9 out of every 10 developers, that is outrageous, 10 years of unit testing and  only 10% of the developers – get it. Some developers we have interviewed said “Yup, I tried unit-testing, it is just a way for management to make us write twice as much code in half the time, I will never do it again”

As Roy Osherove pointed out, there is talk of dividing the developers into 2 groups, “Us” – who unit test, and “Them” who don’t. “We won’t even try to teach them, its their loss.” I can see where this comes from, we would prefer to hire only developers who unit test their code. But the truth is, in hindsight, the majority of the developers working at Typemock, didn’t know how to unit test and learnt it on the job. I actually think that there is already a separation, There always has been one, between the purist (Whether it is Strict-Object-Oriented, UML-Modeling, TDD, craftsmanship you name it) to the pragmatic developer: The highest level of joy, is seeing our product being used, so we need to understand our users, create something that is useful and joyful for them, with the lowest cost of ownership. We will use any tool/process/trick to make this happen.

I had a great discussion with Richard Fennell from Black-Marble over breakfast. Richard told me that Management in companies are focusing at investing millions of dollars on the “user-tests” and see those tests as the ultimate QA solution, while hardly any invest in unit-testing. “We have no quality problem, because we have a QA team”. Now the QA market is a huge and very strong market and unit-testing is a threat to that market. I have heard many QA people, thinking about how this will make them lose their jobs. Richard talked about the normal software developer, who doesn’t have the passion that we have, that see their job as “a job” and don’t spend their free time going to conferences and writing an open source project, they just want to get the job done.

Perhaps this easy-going, let’s wait this out, attitude, is what’s hindering the acceptance of unit testing in the world. It is clear to me that 20 years is too long for this to happen, I know that there is another way, that technology and business value have the power to make that transformation become real.

Oct
16
Comments

Theory Of Constraints, Lean and Schnitzels

Author Eli Lopian    Category Agile     Tags

Roy gave me a copy of “The Cash Machine” Using the ToC for Sales Management. It is a good read, and it reminded me of the principals I learnt several years ago, although this book had a nice twist, and applied the ToC on a human process instead of the normal production line. (There are also bits that can apply to SW Development but I’ll save that for another post).

image What is interesting is that I keep on seeing these pattern. I was making Schnitzels (breaded chicken) for dinner today and my kids where helping me (and fighting over who gets to stand closest to me, but lets ignore that part for now).
Making schnitzels, has a few stages.

  1. Cut chicken breast into small pieces (I did this)
  2. Put beaten eggs in a bowl of (my kids did this)
  3. Put bread crumbs and spices on a plate (my kids did this)
  4. Heat up oil in a pan (I did this)

Now comes the fun bit, each piece must be dipped in the egg, then in the bread crumbs, then cooked in oil until it is ready. My kids started to dip and coat the chicken and I put it in the oil, but very soon the pan was full and the coated pieces started piling up.

I started teaching my kids about lean and about not having any waste and I showed them that the piled up pieces are making it harder to cook, they where taking up room and where in the way and basically making a whole mess out of it. So we decided that we can only have 8 coated pieces (enough to fill the pan) waiting and that once we get there we just stop (and play with the tap water or quarrel).

Then I used the second step of the Theory of constraints and tried to exploit the constraint. By moving the pieces closer and by adjusting the heat we could get 12 pieces in the pan. Now we can change our lean constraints and allow 12 free pieces. I explained this and quite soon we completed the cooking.

imageSo Lean and Theory of Constraints play well together. We had a great meal and learnt some process theories on the way.

 

 

 

.

Apr
16
Comments

Retrospectives should not be about sharing pain

Author Eli Lopian    Category Agile     Tags

Jason Yip has a great post: Retrospectives should not be about sharing pain

Retrospectives should not be about sharing pain and venting.
Retrospectives should be about getting better.

So true.

How do we make sure that we are a problem solving culture and not a complaining one? We use the clearing technique. Every problem must be followed by a controllable action solution and commitment. Dilemma’s are used, if there is a need for the manager to decide, but the team member must give 2 or 3 possible solutions.

Once the team gets used to this, they start coming prepared to the meeting and come up with solutions in advance. After the team gets comfortable with that, the next logical step is to solve the problems as they happen (Lean anyone?) and not waiting for the retrospect.

Mar
16
Comments

Crossing the Chasm and Excellence

Author Eli Lopian    Category Agile, Community     Tags

Roy sent me this podcast: The state of Alt.NET.

Although Scott Bellware imageseems to be angry about the state of things, I am actually seeing great progress in our profession, and the ALT.NET is one of them.

To the point I must agree with him about the following:

1. Alt.NET – you cannot be in the chasm as the chasm is a void, it is when there is no growth, it is when 15% of the .NET developers are practicing Alt.NET. It is fatal to jump over the early adopters and try crossing the chasm before reaching the chasm

2. I’ll take the chance of misunderstanding Scott here, but if I understand correctly, what is happening with ALT.NET is that instead of bringing excellence to software development, it has lead to many developers to follow practices. What we need as a profession is to be professional, is to keep on growing and learning and striving for excellence. 

Only when we strive for excellence, can we do the impossible and grow. It is not easy to become excellent and to grow, but the results are amazing and satisfying

Dec
4
Comments

Unit Tests and Developers under Pressure

imageIn TechEd 2008 David Platt interviewed Roy about the future of  TDD. You should really view the Tech-Talk as Dave is really funny, although he does miss the number of possible TLA’s (which he recursively defines as a TLA = Three Letter Acronym) by 300.

About 5 minutes into the session David asks a key question: “What happens if your boss comes and says: I’m in a hurry, I need this, come on we need to ship this, we need to hurry up, forget about the tests“. What do you do?

I think that David has a valid point that is extremely important to address, as many teams are under pressure and they willing to find any excuses to ‘just code’. This question is going to define where we are going as a profession.

So what keeps us professional, what keeps us from doing cowboy development as Dave suggested that has been proven to lead us to more costs?

As Roy Said, it is a well defined process that will save ourselves from this pitfall, and writing unit tests is one of them. Just like professional teams will not even think of ditching their QA process, developer teams can not afford, in these economic times, to ditch unit testing. As a matter of fact, once you start unit testing you will find that you will be under less pressure!

You will spend some time writing tests (which you would have spent anyway on manually testing the application), but the ease at which you can continue to add functionality without breaking the code, will return that investment in no time. So the quickest way to implement a feature is actually using unit tests! I have seen so many teams make the mistake of not writing the tests, and within a few hours, they are already introducing bugs and are afraid to add features as they might (and probably will) break the code.

So back to Dave’s question, what happens if your boss is in a hurry? Be professional, just write the code and the tests as fast as you can. This is the most efficient way to write software.

Nov
25
Comments

The myth of integration tests

Author Eli Lopian    Category Agile, TDD     Tags

The question of what exactly is a unit test, is one that keeps on plaguing us as a community. I have heard many developers say “oh, no need to test that – its an integration test”.

Well – what is a unit test? and what is an integration test? Guess what: One programmer’s unit test is another’s integration test.

I have talked before about Microsoft getting it right when they called their developer testing tool msTest and not msUnit, and I am going to continue that line of thought. Most developers call any tests that is too complex to automate an Integration test. e.g. GUI or Database. The truth is once the right tools are in place and these ‘impossible to test’ will be possible, and once they are possible – they will be called unit-tests.

So all the tests that we can automate are unit-tests and those that are too complex to automate are integration tests. The complexity can come from brittleness of the tests – so when developing database applications – relying on the actual database will make our test brittle – i.e. Integration test.

We will see in time that with the right tools, we will have more areas that will be called unit tests, because testing them will become easy.

Nov
12
Comments

Estimations and being Agile

There are quite a lot of information in the web about how toimage  estimate tasks in an Agile environments – They are all based on dividing the task to small features and using a statistical technique to estimate the time. But these are quite complex and take allot of resources from the team, and at the end of the day are not exact anyway. Are we wasting our time? Could there be another way?

We already know that we will never really know how long the task will take until we finish it and that we are always estimating anyway. That is why in Agile-Processes we have two estimations – one is a highlight of what can go in a release and the other is per iteration. Still when management asks a simple question – How long will it take to add a feature – the team is stunned and requires several hours to try to understand the domain and come up with an answer that is not exact anyway.

In many companies, it is considered most important to be on time. Soo important that everyone is afraid to be late. Because of this when asked – When can you finish a feature, we will do one of the following:

1. Say: We need to know EXACTLY what user stories are included in this feature so that we can have a planning session to give you the answer.

2. Guestimate and add a huge buffer – make sure that there will be no way that we will be late.

Both are bad for the company – the first requires us to do an up-front ‘design’ in order to get the estimate – wasting time, as we might not even implement the feature. The other gives wrong numbers and might lead to the company making the wrong choice.

Estimating and Event Driven

I wrote before about Improving Agile Development by Event-Driven Management. This is going to be a third option.

3. Understand that it is alright to be late as long as you raise the event early enough. Once we reach that understanding we can be more agile and waste less. We can give the management an estimation – one that we really think is correct (we should still reduce the known features to smaller one- but we will still have many unknowns) , and down the line, the moment that we understand the we won’t be on time – raise the event – and tell the management so – as early as possible to allow the company to deal with it. 

Just like the meeting in the previous post, if we are to meet someone in an foreign location, we can still set up a time, work backwards to see more or less when we have to leave and try to get there on time.
Many things can happen on the way, but as long as you tell the other party that you are going to be late as early as possible. It should still be ok.

So we can waste less time in the estimation/planning/release meetings, do a simple estimation and get on to do the work. If we understand that we are not going to make it on time – simply inform everyone.

Doing this allows us to have to courage to give the estimation that we believe without requiring all the information. It also allows us to make a mistake and be late – as long as we communicate this on time.

Nov
4
Comments

Agile and Event-Driven Management

I have read an article on VentureHacks on Lean (Agile) Companies. In this article Agile = Less Waste

At Typemock we are take Agile development and being an Agile company seriously. In the development we use a scrum/XP hybrid and we use Event-Driven Management for the company. I will explain Event-Driven Management later, but I want to show you the problems that I found in the Agile Development Process.

The End of Iteration is too late

Lets take an example of a feature request that a major client needs. This feature was added as part of the development iteration and the client was told that the feature will probably be ready in 2 weeks. But at the end of the iteration due to its priority the feature was not created. The agile process says that this is ok – as we produced higher value features!

But we have a problem here: The client is stuck without his feature, but only at the end of the iteration that we knew the feature was not going to be implemented. There was no time for management to react to this problem and to solve it. For those who want to know there are a few ways to solve this

  1. Change Priorities
  2. Add a developer from another team
  3. Tell the client when the feature will be ready

How can it be better?

This is where Event-Driven Management comes in. It start by everyone saying what they intents to do that iteration and if they can’t do it (for whatever reason) they have to immediately tell everyone that they can’t make it as soon as they know about it (=the event).

A good example are meetings. Suppose there is an 8:00 am meeting, when I accept I am saying that I intend to be in the meeting. If at 7:45 I am in traffic and I know that I just can’t make it, I can do one of the following:

  1. Turn back and miss the meeting
  2. Try to get to the meeting as fast as possible and appear 30 minutes late
  3. Phone the person I am meeting and tell him that I will be 30 minutes late.

Event-Driven means that we choose option 3. we immediately tell people about the change. Doing this will allow the other person to react to the change and for example reschedule the meeting. At least he won’t sit around and wait.

Event Driven Agile

Doing this with Agile will mean that once we understand that a feature that we intended to do won’t be done – we DO NOT wait to the end of the iteration but immediately tell everyone that we won’t be doing the feature. There can never be a case that we know about missing features at the last minute.

It is quite simple once you use a burn down chart, when the time left on the burn down is more than the time actually left – we can raise the Event and immediately tell the team about it, allowing the company to find solutions to the problems as they arise.

Communication by Events versus Communication by Polling

An event driven company is one where everyone knows what the other teams intent to do and they get are notified when these are postponed.

Whereas polling driven companies are companies where the employees are constantly asked ‘what is the status of’ (because we can’t know if we are going to be there on time). People will wait for others and poll at intervals – leading to waste.

Being an event driven company – will stop waste and make the company much leaner.

Nov
3
Comments

Future of Unit Testing and Economics

Author Eli Lopian    Category .NET Tests, Agile, TDD     Tags

Euan Garden managed the PDC 2008 Panel Session on the Future of Unit Testing, and Andrew has made a short summary.

Unit Test => (Automated) Developers Tests

An interesting thought that come from listening to this panel is that there is a confusion about what unit tests are and I agree that we should really call it (Automated) Developers Tests. This is one of the cases where Microsoft got it right when they called their developer testing tool msTest and not msUnit. Even so, I will continue to call these unit tests, but my meaning is for all tests that developers need to do.

I also agree that many developers still have the concept of “I am a developer so I don’t need to test my code – that is something that the QA team should do”.

Two Futures…

Watching the panel it is obvious that there are two paths that are being considered. The first is that we should not use any tooling at all, and that the pain of doing unit tests will help us write better code – (if you have any pain – it means that you are writing bad code, if you keep on having pain perhaps you are not a good developer), while the other camp say that testing is boring/complex, lets make it easier with tooling

Developer Testing Economics

There is a lot of economic sense in making developers testing there code early on, the early you detect a bug the cheaper it is.

image

So even without creating a better designed software there is still great value in developers testing their code. The thing is that most developers are not willing to test their code, it is too painful/boring. The future is that more and more developers will unit test the code as it cuts the costs of developing software, and that unit testing will be an industry standard. But what is going to make these developers start testing their code?

The Future – Unit Testing will be industry standard

I follow the Rails mantras of Opinionated Software, and my opinion is that we have to make unit testing easier for the masses to follow. It is great to see that Microsoft is also investing in tooling (Pex and TDD in Visual Studio 2010. Other vendors have these tools already – Parasoft .TEST).

The biggest obstacle for developers to unit tests is the need to isolate the code under test. Software is complex, which makes testing it complex. Using the divide and conquer technique to reduce the complexity of the tested unit will render testing these units simple.

Mocking frameworks today are not the same tooling they used to be, they are now isolation tools and these isolation tools will keep developing and progress and help developers focus on simplifying the task of testing their code.