Monday, 7 November 2011

Agile Practitioner IL – Fourth Meeting

I had much fun at yesterday meeting. I really liked the amount of questions and interest people showed. While they didn’t make my life easy, I really enjoyed the conversation and discussion.
for those who missed here are the slides
Hope to see you all again net month and of course at the Agile Practitioners 2012 conference

Thursday, 27 October 2011

Agile Contracts

Agile contracts is an interesting thing. one of the main push back against going agile I get in places is that while agile is nice and all there is no way we can convince our customer to work like this. “they want a fixed price fixed scope deal”. In any case this post is not going to talk about why Agile contracts are a good idea, or how to get buy-in from your clients to sign an agile contracts. This post is going to talk about:

The forces against an agile contract

The power of Inertia

People don’t change easily. The fact that our industry has been using a “Fixed …” contract for several decades now goes against trying anything else. Especially if that something else is substantially different. An agile Contract is exactly that. Different.

Risk

An agile contract puts the risk on the paying side (the customer), he is going to pay for the work done, even if that work is of lesser value. Naturally if its value is low enough  he can bail out. But still the risk is on him. While a “Fixed …” puts the risk on the development team. they need to fulfill their part before they get paid.

Trust

our industry has not been that great at delivering working software. (to say the least). Most software projects either fails completely or significantly does not meets expectation (either they miss the timeline, exceeds the budget or reduce scope)Potential Profit. An agile contract actually says exactly that. By going for a flexible scope (or time) we actually say we don’t know exactly what will happen, we don’t know what we can deliver (or when). That’s a hard message to tell the one who is paying.

Potential Profit

This one is a little elusive. One of thing we do as a development team when we go for a “fixed …” is add buffers to mitigate our risks. At one place I used to work I saw a two days chunk of actual work being priced as 11 weeks for the client. And he was willing to pay (there is a cost for putting the risk on the developers). For us as a development team this represent a significant potential profit. If we could just estimate accurately and actually finish the work in the time we say we can. The buffers just become easy money. No matter how many times we under estimate work, every time when we do a new estimate we are always sure that this time it will be different. This time we have considered everything. After all we are smart people.

As you can see there are strong forces affecting both side to resist going for an agile contract. Can you think of more?

Wednesday, 26 October 2011

Can you spot the Contradiction?

Here’s a job description I got over the mail (the original message was in Hebrew so I’ve translated):

Subject : Project manager – Control of Agile software

A project manage with control of Agile software is need for an international development company dealing in Wireless Electronics

  • Must – BSC in engineering
  • 1-2 years of experience in project management or in project scheduling and task tracking as part of the project team
  • Experience in Configuration management – significant advantage.
  • Experience in production processes, moving from research to production – an advantage
  • Must have knowledge in Excel, Ms-project, Agile software
  • Great interpersonal skills, teamwork, ability to work under pressure
  • Fast learner of systems and processes, ability to dive into details
  • Excellent English
  • Willingness to travel

Can you see what’s wrong here?

(i.e. why does a real agile person will not get close to this job?)

Monday, 24 October 2011

“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.

Monday, 17 October 2011

Agile Practitioners IL– Fourth Meeting

Agile Practitioners IL - 4th MeetingJust wanted to let you know that the Agile Practitioner group will be meeting for the fourth time on November the 6th. This time I’ll be giving the first part of the session and I’ll be talking about how agile can be adopted by a small part (maybe a single team) inside a bigger organization that might be using other more traditional processes.
Like always entrance is free but registration is required. So please register here (SAP our hosts did ask that you will remember to bring your event ticket to the meeting)
You all are invited to attend and I also ask you to help us attract more people to the meeting. Please invite your friends, colleagues or anyone else you feel might be interested in coming. We really like to  grow up our relatively small community.
And last come if you haven’t already and join us at linkedin:  http://www.linkedin.com/groups?gid=81807&trk=hb_side_g

Monday, 10 October 2011

Your code should Always be working

Source control branches is always a good topic to argue about. if you read any of my previous topic (or just know me a little) you are aware that personably I think those to be a complete waste of time and effort. My personal experience (which is validated against places I consult in) is that most usages of branches are covering some inherent process problems that best be solved instead of hidden. but that’s not what I want to  talk about.
what I do want to discuss is one of the main argument people raise for justifying their need to use source branches. and usually it goes like this:
yes we would love to work on one main trunk, we see the great value in that. However, not all programmer knows how to work their code without breaking the rest of the system. therefore we use branches to prevent the system from breaking during development of new features. and we integrate their work based on needs and stability.
Frankly I can relate to this. I can understand what is missing here. We need some good strategies for working on code without hurting system stability. so here are some options for you.
Invisible Coding
The first and most trivial technique is using build it (in the programming language) mechanism for disabling code. Yes something like the infamous #ifdef directive for C/C++ that exists in most (all) modren software languages. The main idea here is that all new additions to the code are marked as disabled until they are ready be activated and integrated into the main system.
For most this would seem as an ugly patching/hacking and most programmers has a a natural dislike of such an option. and probably with a good reason. After all if the code is not active what is the big difference than just using a separate branch? well not much, the only real benefit in this is that at least one side of the integration is always done. when you are working on a new feature and still work on the main trunk, even if your new code is disabled, it is always updated with other changes being done to the system. And since in most cases enabling/disabling the new parts is quote easy. With just a little care you can do parts of the second side of the integration in an ongoing fashion making the final integration easier, safer and faster.
Decoupling of New Code
The second strategy takes the “invisible code” approach one step further. the main idea here is to write the new code into the main system, but this code will be decoupled from the main code in such a way that it will be easy to prevent actual usage of the new code until it is ready. Its like building a new part beside the main system and only connecting it when it is good and ready. technically speaking it’s a little harder to achieve and sometime require a little bit of juggling and some getting used to thinking this way. On the upside this make sure that all new code is integrated into the system in such a way that only the final steps of the integration (making sure everything works) is left for the end. the back and forth tedious merging is done along the way. Also, from my experience most developers find this approach natural and tend to work like this anyway when adding new stuff. However, the down side, is that in many cases the harder part is to actually to the connecting of the new parts into the existing system. sometime you find that you missed some staff that invalidate part/most/all you work done in isolation. I usually advice people trying to go this way to start by first  solving the connecting part. that is start by making the system integrate into a “dummy” new part making all the calls do nothing. and when that’s ready go over and fill in the missing parts.
Work Small
This is kind of a process work around. it has nothing to do with how to write code. The main idea is to always work on small features. so small that in fact they can be started and finished in a couple of days  making the use of a branch just a big overhead with no actual need. If you can start and finish in a matter of days, you can just work on your local copy focusing the actual code changes in a very short, delivering everything at the end. Actually this is just like branching but since it is for such a short period of time integration will not be an issue and most likely merging will not be required.
actually this strategy has all sorts of benefit outside the technical domain so it is a recommended idea no matter what else you do, and if/when needed it can also be combined with other strategies
Test Automation
Well this is probably the one thing that will make your code work at all time. if you have a good suite of automated tests that does a decent job at covering your system, the rest just falls into place. You just work on the main trunk and make sure that everything continue to function by running the tests after each change and before delivering. If you broke anything the tests will let you know, and you can just find another way of doing this. Of course having such a suite is something that sadly most people are short on. and those that do have are usually already solved this problem a long time ago. but lets face it you do need test automation no matter how you work.
The Mikado Method (The Missing Link)
That’s one is new for me, while I have encountered this over a year ago, only recently I managed to actually dive deep and read the book (an excellent one BTW, which can be downloaded here (for now)).
and for me that was the missing piece in the puzzle, the main idea of the Mikado method is turning the problem upside down. you start by stating you goal, you find out what are the prerequisites for achieving you goal, you apply them to your system, see what breaks, find what’s need to be done to complete the prerequisites, writ it down in a graph and then revert your system back. then we repeat the process for each derived prerequisite and continue to so until we find actual things that can be done without breaking the system. This is a very short and probably not so good description of the Mikado process. but the book does a great job at that so just go ahead and read the first two chapters to get you going.
The great thing about this method is that it uses the power of a source control system, in way that allow a programmer to chart his way until he maps all/most of the things to do in order to reach the Goal, and only then actual work on the code is started. This allow one to start working in small steps from the end to the start while keeping the system intact all the way. at the end this is just taking the “Work Small”  strategy and applying it to the “technical” side, resulting in breaking down the work into small technical steps that can be safely taken. and the best part is that this is an actual technical technique that can be practiced and mastered.

This are the strategy I have used and will use and for me those things work. I’m sure most of the things stated here works well in combined together and the trick is to use the right tool for the task. would love to hear about more techniques for handling the same situation.

Wednesday, 5 October 2011

Agile Practitioners 2012 Update

image
I think this is my first post on the conference, so lets start from the beginning.
On January the 31st. We will be having a big agile day conference locally in Israel. We have been working in the last few months to make everything happen, from bringing in international speakers, looking for great content locally to arranging for a place to host the event.
we also brought up a website for the conference: http://agilepractitioners2012.com/. go there to get more details about what the conference is about.
I would like to let you know (and remind those who do know) that the call for paper is still open and we are still looking for great sessions given by great people to have in the day.
if you have anything worth sharing please come and suggest a session: http://agilepractitioners2012.com/call-for-papers/
the call for paper is open until October the 16th, don’t miss it.

Monday, 3 October 2011

TDD for Legacy Systems

We know test automation is crucial probably even mandatory, and TDD is a great practice to use, but lets face it our existing system is not test friendly to say the least.
so now what?
TDD for Legacy system is  my way to help people tackle this problem. During this two day training we will learn how to cope with existing systems. We will go over the basics of Test First methodologies and learn how to turn a system from a big  chunk of legacy code, into something that is covered by a suite of automated tests. we will discuss issues of setting up a continuous integration server, different type of testing that can be applied, how to tackle existing system design and how to slowly but surely improve our code base while writing automated tests for the existing code.
the training will assume no previous knowledge of test automation, however it is  hands on and does require previous experience in programming (at least one year on a real live system).
if you are interested and want to learn more details about the course syllabus and content can be found here
and of course you can just register here
so don’t wait up, take you r first step and come learn about modern software development.

Wednesday, 7 September 2011

Agile Practitioner IL - 3rd Meeting

Sunday evening we met for the 3rd time. This time Roy Osherove discussed 10 mistakes team leaders make an updated version of the slides can also be found here.
During the talk Roy mentioned several books, out of those I really recommend Johanna Rothman & Eshter Derby, Behind Closed Doors: Secrets of Great Management. For me that book was a career changer. I recall reading it as a team leader and for the first time I felt someone actually wrote a book that explained to me what a team leader job is all about. Also the book is filled with practical techniques that can be applied as is. from planning to conducting one on ones. Just the sort of advice I needed at that time.

Scrum Master vs. Team Leader

Towards the end of the session a discussion rose regarding the place of the scrum master and about the amount of authority he as over the team.
On one hand we all know that a scrum master is not the team leader. and it is considered a bad practice to make the team leader into one. However, it is also clear that the Scrum Master as defined by his roles and responsibilities, should lead the team helping them to become better at what they do. and in fact in most cases the natural candidates for becoming the scrum masters are the team leaders.
So where does the line from leader to manager is drawn?
Actually I don’t have a good answer for that. My gut feeling tells me that a “good” team leader, will fit the role of a scrum master very easily. Yes there are some traps and pitfalls that he should avoid, but if he is “good” that should not be a problem. However, many team leaders are not “good” and there is a real danger making them scrum masters. While as a team leaders they might manage to still function, as scrum masters they are not equipped to handle an agile transition which by itself is hard enough. In most cases they just ruin any attempt at any kind of an agile process. In my eyes the job of a scrum master is so much harder and it take a more experienced person with the “right” state of mind to do a good job. Leading a team is much harder then managing it.

The “Good” team leader

the million dollar question is of course how to sort the “good” team leaders from the rest?
  • Are they the team leaders which demonstrate the best productivity in their teams?
  • Are the the one most liked by their teams?
  • are they the ones most appreciated by their managers?
  • or is it something completely different?
don’t really know.
The only thing I did found along the way, is that there is a strong correlation between team leaders exert minimal authority over the team to those who becomes great scrum masters. So when I see a team leader which doesn’t “tell” his team what to do, and instead asked them many questions I know that there is a good candidate for becoming a Scrum Master.

Tuesday, 6 September 2011

Making your team manage their own work

I really think that team leader should stop being the ones which split the work into tasks and decide who does what.

I’ve written more about this subject and it was published here at the 5whys blog. (which is an excellent reading materials for team leaders)

Monday, 5 September 2011

Bug: $10, Future Bug: $200, Angry clients: $5,000, One TDD course: Priceless

When you write code for a living, mistakes can be expensive. They can create bugs that will crop up in the next version or the version after that, they can cause problems down the line for the end user who can't use the software and worst of all, they can create bugs that you spend longs days (and nights) working to find before the release.

One way of avoiding these mistakes is Test Driven Design - write the test before the code and the bug (if any) is easy to find. And a course in Test Driven Design is not that expensive - and even less so today :)

http://goo.gl/3VMqM

Thursday, 1 September 2011

Introduction To TDD – Early Bird

Just wanted to remind that you can still get the early bird pricing for my upcoming training on September the 18th. People who will register by Tuesday the 6/9 will get a 50% discount for the course (making the cost only 600NIS per person).
Details about the course can be found here,
Registration details can be found HERE
If you have any other question feel free to contact me

Thursday, 18 August 2011

The value of a 1 day introduction to TDD workshop

Next month I’ll be teaching a 1 day Introduction to TDD .NET workshop. And I was asked to explain what is the value of attending such a workshop. Clearly one can’t learn how to TDD in a single day, and indeed this is not the goal of the workshop.

So what is the value in a single day Introduction to TDD workshop?

I will let the reader judge for themselves. However here are the things I expect to cover during the day.

  1. Go over the basic rules of the TDD practice
  2. Explain and demonstrate what a testing framework is used for.
  3. Introduce base Isolation principles.
  4. Explain concrete ways for mastering the TDD skill.
  5. Go over the humps of pain – i.e. the main obstacles for doing TDD
  6. Let participant practice their firsts steps in a safe environment.

I expect people to come out from the workshop with the following:

  1. Knowing the costs involved in TDD.
  2. Understanding the benefits.
  3. Know what needs to be done in order to actually learn it
  4. Be aware of the main obstacles and pitfalls in the road for mastering TDD

So is all this worth a single day of your time?

if you think it is you can Register Here

Sunday, 14 August 2011

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.

Mocking framework

pick one of the power tools available:
(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/

Sunday, 7 August 2011

Agile Planning is just Enough

Actually Agile planning is based upon two main principles:

  • Just enough
  • Just in time

that is, at each stage we plan just enough to get us going and answer the important questions at that stage and than we stop.

In this post Gil talks about agile planning how it mainly focused on short term. Well Gil you missed some important staff about what you call Agile planning.

lets start by saying that talking about agile planning as a concrete thing is basically misleading, agile planning is just a set of very basic principles (which I tried summarizing above). One need to refer to concrete planning practices in order to udge them.Planning is scrum does not look like planning in Kanban which does not look like planning in XP…

The example used is taken from a medical field, in which the stake holders

“needed to know everything would be ready in time, three years in advance.”.

Well sorry there is no such magic in our field. NO one can know what will happen three years in advance.

when you claim to be able to do that you are simply lying, both to your sponsor and probably to yourself as well. You can estimate, you can guess or you can extrapolate based on prior knowledge.

you will never KNOW.

Even when you sign a contract with millions of dollars in fines for being late, you cant know. you are just doing an educated guessing taking all the buffers and safeties you need in order to hopefully meet you goals in the given time. And BTW in most case you don’t (just check out Chaos report if you don’t believe me)

Long Term Planning

Gil is right about one important thing, almost every project need a long term plan. Question is and always will be is just how long do we need our plan and how detailed do we need it to be.

In scrum for example, there are 3 levels of planning:

  1. the daily planning (done in each daily meeting) – we plan in extreme details what will be done in the next day
  2. the sprint planning – we plan in details which tasks will be done during a sprint ( a few week ahead)
  3. the Release planning – we plan the list of stories which we will deliver in the next release (typically 3-6 months)

And here Scrum stops.

That doesn’t mean there are no longer term planning, just that the longer term is “out of scope” for the basic Scrum process. u will still need a product roadmap, you will still need a strategic planning. and maybe just maybe (like in the example Gil gave) you will need to give a list of expected features for the next “big” version. However this kind of planning will always be more vague, will deal in general capabilities we would like our product to have and at the end will always be open to interpretation. it would never be concrete enough to actually start working on.

The nice thing that at the end my recommendations and Gil are the same (well we do basically believe in the same things):

do a release plan (3-6 months ahead) make sure you are working on the highest priority features and make your best to develop them as fast as you can, and always keep your progress visible top your customer.

So lets do a reality check, planning is nice and important, but “responding to change over following a plan” is what makes agile processes works. The longer the time frame you are planning chances are higher that this change will be bigger and come sooner.

Wednesday, 20 July 2011

So how are design pattern working for you?

A confession. I never did manage to make design pattern work for me.

A disclaimer. I don’t think that this is because design patterns are in any way “wrong” or “bad”.

Yes, I do use them occasionally and Yes, I do know a fair share of them. However, I always have this nagging feeling that I should know more patterns, and at the end of the day, when I’m actually designing my systems I rarely go:

“ahmm I can use the XXXX pattern to do this”.

So why is this so? why after so many years of using design patterns talking about patterns and even arguing quite a lot about them, I still can’t make them work for me?

I wonder…

The human brain as a pattern matching machine

Start of July I attended at Vipul Kocher session during the SIGIST conference, in his session Vipul talked quite a lot about patterns and specifically about testing patterns. All and all it was a very interesting session, out of which I would like to repeat two main idea’s. First, Vipul initial claim was that our brain is basically a very sophisticated and efficient pattern matching machine. We use patterns on a daily basis. We see patterns everywhere, we recognize all kind of patterns we create new pattern, and often enough we even use Meta patterns (patterns which are used to create new patterns). No wonder our brain is such effective in matching patterns.

Learning to speak

Vipul’s second idea I would like to quote, is the fact that human apply this pattern matching ability in or language learning process.

And in the first time we are not even aware we are doing so.

When learning our native tongue, our brains learns patterns for matching single words, to match complete sentences, to match grammars rule and to match common mistakes. And it does so without us being conscious to the process.

The second time we learn a language the process is different, instead of absorbing the patterns instinctively, we apply a conscious learning technique.Instead of understanding specific word, we translate meaning from our native tongue, instead of deducting the grammar we LEARN grammars rules from books (or a teacher). This is also a way of learning. However in general the end result is inferior, usage of our native tongue will always remain easier and will always be of higher quality.

Misplaced Design Patterns

When talking about design patterns there are a couple of anti pattern I see in their usage. Again, I don’t claim there is something inherently wrong with patterns. I do see however problems with their usage. The most common issue I see, is a problem in applying patterns. Specifically, too often I see misplaced design patterns scattered around systems. Look at your current system you are developing. How many singletons do you see there? are all of them necessary? how many times you have argues with someone that while XXX is a great pattern, using it here seem to be out of place?

Initially I thought that this is caused by simple lack of pattern knowledge and understanding. However I think the reason is simpler than that. Our brain is always on the look for patterns, our thought process is rigged to order the world around us into known patterns and shapes. It does so instinctively all the time, and specifically during design it tricks us to see patterns which actually might not be there. It takes a really trained eye and conscious effort to compensate. Failure in doing so results in having a misplaced pattern in our system.

Design Pattern as a language

Haim describe in “Design Patterns and the Tower of Babel” one very important benefit of using patterns. Patterns serve as a common design language for us, and this is good.

However there is a catch. At least for me, the Design Pattern language is our second language. As a second language I will always find it harder to use. When using a secondary language (as in English ), I always struggle for the right words (patterns), I fail to understand the nuances behind them, I make stupid grammar mistakes and occasionally I use inappropriate words (if you don’t believe me read this article again). When I use Design pattern I feel the same, no matter how much effort I invested and will invest in learning patterns, I think that for me the cause is lost. I will not be able to use design pattern as my “native design tongue

So what should we do?

I see two options, the first is making sure that pattern does become the native tongue for new comers to our profession. On the upside design patterns has got a hold and I do see this more and more new comers learn them very early. However,I think that this process is going too slow. In order to actually see this done on a bigger scale, design pattern should be embedded into basic training and should be thought at universities (which I haven’t seen happening yet)

The second option is for people like me, those that will always have a different native “design tongue”. Like always, the first step is to admit that we have a problem. The problem is that the pattern language will always feel uncomfortable and be less effective for us. We still can and should use it, but when we do, we should be aware that we are “translating” and in the process our meaning can get twisted.

This is very frustrating. Especially when a “native pattern speaker“ meet a “second langue pattern speaker” like me. No matter how I try to avoid it, I end up reverting to my native language in order to “keep up” and when I do confusion start to hit (resulting occasionally in some heated arguments). Therefore the second step is to always keep in mind and be aware that this is happening.

When two “Foreign pattern speakers” meet

And last, and this is what I should always remember to verify, sometime on the other side there is another “pattern as a second language“ kind of guy. When this happen to be the case, we can sometime, just maybe, skip the whole pattern things. Chances are that it will be easier to communicate using our native design tongue.

So what are you?

  1. a native design pattern speaker?
  2. learnt design pattern as your second language?

Thursday, 7 July 2011

Agile Practitioner IL– First Meeting

First group meeting went great. (Here is the group forming)

006

Thank you all for coming and participating

Elad Sofer

008

which seems to be enjoying himself here, just blogged about it and I couldn’t have said it any better than myself.

I will only talk about the second part of the meeting.

During this part, we tried to get a feeling on where the group would like to take this forum/meeting/activity.

W attempted to gather some ideas on the following:

  1. What content would we like to discuss
  2. How we would like o conduct these sessions
  3. who would we like to hear talking.

and after some discussion and debate:

009 012

Here are our main “finding”

Topics of Interest

The four winning topics are:

014

  • Continuous Deployment
  • Agile for Executive (how to convince and how to include them in the process)
  • Agile in Enterprises
  • How to start the development of a new product using an agile method

the runner-up topics were:

013

  • choosing content for a sprint
  • Agile in none SW development projects (support, Maintenance, IT,…)
  • Scrum in details + real life experience
  • dealing with the Integration phase in an Agile process.

How to conduct these meetings

About the how, the consensus was that a session which is divided into two parts in which one is a lecture and one is an activity based was great.

another idea was as follows:

  • 1/3 Presentation
  • 1/3 collecting ideas for discussion and choosing which ones to discuss
  • 1/3 Discussions in small groups on the above

Who would we like to hear

and last on the who front we got 2 local names Roy Osherove and Oren Ellenbogen (consider yourself invited), and two international speakers: Martin Fowler, Alistair Cockburn (I wonder if we can get on of them to visit)

and just before I forget, I would like to thanks everyone who helped make this group come into life.

Especially Elad and Ilan who partnered up with me, and really did most of the work to create this group. To Ohad Israeli and Nice for hosting the event giving us their excellent facilities to conduct this meeting. and Last to Typemock who sponsored the event and made sure we wont stay hungry

Tuesday, 5 July 2011

TDD .NET Course

Next month (starting on August the 8th) (Starting on August the 14th) I’ll be conducting a public “TDD .NET” course . Registration is now open for everyone, so go here and book your place.

The course TDD.NET is based on practical experience and lesson learnt gathered over the past several years. The course main goal is teach basic concepts of TDD practitioners while giving participants enough practical knowledge to start practicing on their own.

Monday, 27 June 2011

5 Reasons for Doing Scrum

A while back ago I gave a talk about what are the main benefits any organization should expect when changing its process into an agile (Scrum) process.

Here is the recording of that session. Its about 50 minutes long and its in Hebrew.

Hope you enjoy it

Monday, 13 June 2011

Open session With Jurgen Appelo

As a prequel to the first Agile Practitioners IL group meeting (register here). Jurgen Appleo has kindly offered to give a short, one hour, session during his visit next week. I know this is a very short notice but knowing Jurgen, I’m sure it be worth while.

The event is limited in space so for further details and registration go here. And don’t forget that we would still like to see you all at the first formal group kick off meeting.

Monday, 6 June 2011

Video of my talk at “QA & Development In Agile” conference

Last month I spoke at “QA & Development in Agile” gathering. SELA were kind enough to video my talk and to make it avail;able online.

Details about the talk (with the actual slides) can be found here.

and if you want to tune in and listen to the actual talk (about 30 minutes in Hebrew) you can do it here.

Also I would appreciate any feedback you can share. So feel free to add your comments.

Sunday, 5 June 2011

New Agile User Group – First Meeting

I‘ve been wanting for quite some time now to setup a monthly meeting for people my_Logowho are interested in Agile. Since the demise of “Agile Israel” meetings I haven’t seen any sersiou sattempt of setting such a group, although I feel that many in the industry are interested . Therefore I would like to invite you over to the first group meeting of the “Agile Practitioners IL” .

This session subject will be "Feedback". We will have Elad Sofer (which is also a co-founder of this group) talk about "Feedback - The secret ingredient of success", why feedback is so important for success and how it is used Since this is our first meeting we shall also try to gather feedback from participants on what else they would like to hear, and how they would like to see this monthly meeting evolve.

If you want to get involved, please RSVP at http://www.eventbrite.com/event/1774314021

Location:

Nice System

Hapnina 8, Raanana.

Time:

Gathering starts at 17:30


You can join the Agile Practitioner IL group at http://www.linkedin.com/groups/Scrum-Practitioner-Israel-81807?trk=myg_ugrp_ovr


Food and drinks are sponsored by Typemock LTD.

clip_image002

Tuesday, 31 May 2011

Flaw in SolutionContexts.GetEnumerator

I’m guessing that this post will be useful to a very small number of people if at all. However there might be a bigger lesson here for people writing their own collections and that is how not to code GetEnumerator method.

but first some background information.

when working with a visual studio add-in I needed find out weather a specific project is excluded from the build cycle.

the DTE provide interfaces and object to access this info and the code I ended up with looked like this:

   1: foreach (SolutionContext context in 
   2:    ApplicationObject.Solution.SolutionBuild.
   3:        ActiveConfiguration.SolutionContexts)
   4: {
   5:     if (context.ProjectName.Contains(project.Name))
   6:         return !context.ShouldBuild;
   7: }

However, this code resulted in an exception popping from time to time which took me a little while to understand.

the exception I got was :

System.ArgumentException
The parameter is incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))
System.Collections.IEnumerator GetEnumerator()
at EnvDTE.SolutionContexts.GetEnumerator()

where the line number pointed to the foreach statement.

After some digging I found that this happens if in the solution you have an unloaded project as part of the solution. and the fix was quite simple jut replace the foreach with a simple for resulting in something like:

   1: var contexts = ApplicationObject.Solution.
   2:    SolutionBuild.ActiveConfiguration.
   3:    SolutionContexts;
   4:  
   5: for (int i = 0; i < contexts.Count; i++)
   6: {
   7:     try
   8:     {
   9:         var context = contexts.Item(i + 1);
  10:         if (context.ProjectName.Contains(project.Name))
  11:             return !context.ShouldBuild;
  12:     }
  13:     catch (ArgumentException)
  14:     {
  15:         //this is thrown when a project is unloaded
  16:     }
  17: }
  18: return false;

Now I can understand why an unloaded project will throw an exception if you try to access its configuration data. What I don’t understand is why they didn’t handle this inside the GetEnumerator and instead choose to crash it as well.

I think this is a mistake, in general if a piece of the information is missing don’t fail the entire operation just exclude that piece from the result. that way you will enable the user to decide what to do with the info he does have.

what do you think?

Thursday, 26 May 2011

Don’t you love useful error messages?

image




Ok now what?

Tuesday, 24 May 2011

Exporting Code Metrics from Command Line

A couple of months ago Microsoft released a tool enabling to gather code metrics on code form command line. (detailed post here).

While it took me some time I’ve updated my Msbuild custom tasks project and added an Msbuild task for better integration of the tool into a build cycle.

The task enable the exporting of metrics for a given solution and includes an xsl to transform the resulting xml into an html report.

(older tasks in the project allowed running all tests (using mstest) in a given solution and exporting VS coverage report to an xml)

To download the latest release go to here, and if you have any questions or additional requests contact me either through the CodePlex forums or directly.

Monday, 23 May 2011

Presenting at Sela’s Developers Days 2011

image

Towards the end of June I’ll be participating in Sela’s “Dev. Days” conference. Unlike other conference, “Dev Days” event is a collection of 1 full days workshops that will be given over the span of an entire week. During this week there will be 25 different workshops in various subject aiming at beginners and advanced Developers alike.

My part in this event will be 2 workshop that I’ll be having:

1. Introduction to Scrum

At this workshop ill be going over the principles of agile. I will show the basic Scrum process and technique and will demonstrate the key differences between Agile way of doing things and classical waterfall approaches.

If you are want to know what the agile buzz is all about I really recommend attending this day.

2. Introduction to Test-Driven Development

TDD has established itself as one of the leading practices in the Agile community. However there are several obstacles in actually starting to TDD. The goal of this day is to give all participant a good starting point for actually starting to code in the TDD style.

If you ever wanted to give TDD a go, but always found it hard to start. Maybe this day will get you going

2 other related workshop that might be of interest in the context of agile and testing are:

Team Foundation Server 2010 and Visual Studio 2010 and Visual Studio 2010 Testing Tools. but of course the week has many more very interesting workshops. for the full agenda go here and if you want to register follow this link.

Sunday, 22 May 2011

My Presentation at “QA and Development in Agile”

This is the presentation I gave last week over at the “QA and Development in Agile” conference (including some extra slides the I didn’t have the time to go over). Unlike other presentation this one was solely process related and not about any tool so I hope everyone enjoyed it.

The main pint o the talk was that its more important to optimize the team feature throughput than the team utilization and I hope I managed to get it across.

Scrum Project Management

Would you like hear me present? Contact me!

and in any case would love to get your feedback on the experience.

Monday, 2 May 2011

Moving from Fix price to Agile Contracts

One of the major roadblocks in an agile transition is the fact thatcontract when adopting an agile approach fixed price, fixed content contract does not make much sense anymore.

sure, some organizations are succeeding in doing agile under such contracts but one of the promises of Scrum is to be able to easily cope with changing requirements, and change the work plan to contain the most valuable features seen at that time.

On the other side, after so many years working under fixed price,fixed content contract its really hard to change especially since much of the time the other side (the one paying) is not really involved in the decision to adopt agile.

Its all about risk

a couple of weeks ago I had the chance to talk Giora Morein during a conference, after a while we started talking pricing schemes at which point Giora pointed out that when working under a fixed price contract, the risk involved is mostly placed on the side providing the services, while when using an hourly/daily rate most of the risk is taken by the paying side.

I believe that this fact is part of the problem we face when trying to adopt to an agile contract. The problem is how to convince a customer that is used to having the risk placed at the supplier to accept the risks involved in committing to a project under a flexible budget and content.

Moving Into an agile Contract

The first thing I found useful when I try to switch to a flexible more agile contract, is to start by acknowledging this fact. I than counter to with the benefits of such a move, focusing on the benefits the client will see.

In many cases this is not enough and the customer will still choose to use the same fixed price, fixed content agreement and in this situation I found the following steps to be very useful to establish a level of trust needed to actually change the working contract.

In order to actually change anything the first order of business is to sort all requested features by order of importance. In most cases this is grasped by the client as a reasonable request and it opens several channels of communication whiled doing so. its very important that the client will be involved in this as much as we can since this phase build the basic understanding both parties can build upon later on.

Second I try to add the following key points to the contract

(since all this points are actually controlled by the client most have no real objection to include them in the agreement):

1) Scope can be changed - The client can swap any requirement/feature by a new one of similar size, as long as it conforms to the basic priority scheme.

2) Priorities can change - by the client at any point of time. These changes will be reflected to the work plan (excluding things which are currently under way).

3) The client can take a working version of the work so far. In fact he is encouraged to do so and provide any feedback he can n it.

4) Termination - at any point of time (subject to a reasonable fee – I use 25-30% of the remaining cost) the client can terminate the project taking all the work done so far.

I have tried this scheme on a couple of occasions and found that after a few times the client actually invoke any of this clauses. He usually see the benefits involved in such an agreement and the next time he actually insist on this ability and is much more open to a working under an “agile contract”.

Thursday, 21 April 2011

How do you decide if Agile is suitable to your project or not?

I get this a lot and usually I don’t give a simple and straight answer. This time I will make an exception.

So how do you decide if an agile is suitable for your project or not?

Simple! if you ask this question the answer is NO. I’ll repeat Agile is NOT suitable for your project.

wait wait, an agile coach saying that agile is not suitable???? what the…????

Yes. That’s exactly what I’m saying, as long as you keep asking this question, clearly you are not at the point of adopting Agile into your project.

I have found that I get this question from 3 type of people:

The agile practitioner/coach/consultant.

I ask you: do you really need an answer for this? who is doing the asking. Most likely these are just repeating the question. Since they have been asked by the other types. So for you, I hope this post will give an alternative answer to give.

People who have encountered Agile and think it’s nonsense.

These people have already decided against Agile. They are just seeking for excuses for not doing it. The hard truth is that adopting Agile requires people collaboration. chances for success drastically goes down if the people involved don’t want to go all the way and actually adopt agile values. So if you don’t want to do Agile, don’t do it.

Why seek excuses? clearly Agile will not work in your project, so until you decide to really give it a chance don’t try it.

Agile newcomers who doesn’t know what it is.

Everyone working in an agile way passed through this point. at this point you probably heard some stuff about Agile/Scrum/Kanban… you have heard rumors and stories about great success however you are not yet sure what it is and how does it fit into your process so for now you just want to know whether you should invest time and effort in this.

However if you are still at this point, don’t try it just yet. Simply because you are not yet ready. Most likely you are lacking the needed knowledge to make it work. Adopting an agile methodology is not a trivial thing, it requires knowledge and expertise. Agile implementations can and does fail and one of the common reason I see is partial knowledge of what Agile is all about. so until you gain the needed knowledge Agile is not (yet) suitable for your project.

Basically I think this is the wrong question, instead you should ask yourself the following:

  • How will an Agile approach can help me improve?
  • What can be the benefits I might gain if I’ll become agile?
  • What will be my impediments for adopting an agile process?
  • How can I increase my chances for success in becoming agile?
  • What might be the risks if I become agile?

After answering these question you can decide how to proceed.

 
Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | Walgreens Printable Coupons