One of the responsibilities of a great execution team is to make sure they will deliver in great speed and great quality, over time. “It’s a marathon, not a sprint” might be a confusing statement if you’re actually using Sprints in your development process ;)

What do I mean by “confidence building” and how does it affect you? Well, I believe that you need to earn others confidence over time, making sure your customers, internal and external, are happy with your results. For that you’ll need to make sure you understand what’s expected from you, to reach deadlines on time, to raise the Red Flag early and offer alternatives, to deliver product with great quality and to produce estimation that prove themselves as meaningful. Your job is to keep the execution machine at full speed and building the confidence as you go.

My recommendation is to make sure your Sprints will contain some internal maintainability time so you could stay on track rather than “have a good Sprint once in a while”. Here are a few thoughts:

1. Bugs elimination – making sure the backlog is not overwhelming. Pick wisely, based on ROI given by product and technical teams.
2. Provide rough estimation on the Features in the roadmap, review previous estimations and see if you were close.
3. Push small POC for risky features to come.
4. Create technical design for big/risky features you plan to address next sprint.
5. Eliminating technical waste – small refactoring to enhance team productivity.

You can either treat them as features, or simply buffer some availability of the team to handle this.

No matter what, do not burnout the trust people have in you; your boss hired you because s/he trusted you to do well, it doesn’t mean you don’t have to work hard and continue to earn her/his confidence in you. It is a marathon, after all.

User Stories became very trendy when Scrum became popular due to its smaller abstraction level; this made it possible to break big Feature and adjust its pieces into a single Sprint. I think this was taken too far, where User Stories sometimes completely replace Features. Not only I believe that Sprint should not be a release unit, I also believe that User Stories are not the correct work unit in a release or a Sprint:

1. Losing the why –User Stories by themselves are incomplete: they are missing the *why* - why do we think it is wise to develop this all experience? User Story describes only a small portion of a full experience. If we want to have real discussion on the value of a new capability, we must understand the full picture. The value always lies in the forest, not in the trees.

2. User Stories are usually not valuable to the customers by themselves - If you break a Feature into 20 User Stories, how many completed User Stories are enough to release the Feature? You cannot give your customer the Story of “A user can enter his password, the system will validate it by [rules]” without actually letting him register to the system. Your customer might enjoy tracking the Feature as you develop it this way, but you probably cannot release a version with 2 User Stories out of the 20 needed.

3. Maintaining another abstraction is expensive – what happens if a Feature changes? If you’re holding your User Stories separately, you’ll need to update them. Sometimes, as mistakes being made and it’s hard to sync papers, you’ll update one and not the other. So your business team, as an example, will work with the Feature paper but your QA team with the User Stories. Abstraction is smart only if it is beneficial over time.

I believe that User Stories are too pricey to be used as planning and execution units; they abstract a lot of the significant value Feature has to offer and introduce fragility in the process.

What User Stories are good for?

I would use User Stories only as a lingo between developers and business/marketing teams. They are small enough to be discussed without thorough background and big enough to explain behavior and expected outcome. I would not use User Stories to plan my sprints or my releases; I would aim to work in units I can deliver to my customers and discuss value of complete experiences.

How to adjust a big Feature into a Sprint?

More on it to follow…

Sometimes, multiple Features offer multiple experiences to the same motivation/goal/pain.

This is why it’s so crucial to document the why, the motivation, the pains, the reasoning behind a Feature. Although “The why” is crucial, it is not enough by itself. A great Feature must also detail the experience our users will enjoy, may it be capabilities, flows and look & feel. Only then, we can understand the purposed reality, before it is a reality - before we develop it and spend money to bring users to play with it.

With that, a real discussion on whether this Feature will be the best way to achieve this goal can take place. If you let your team be part of your vision building, by sharing the pains and goals, you can get invaluable internal feedback during “thinking time”. Fixing the Feature flows, improving usability or look & feel, before it’s developed, is always cheaper than doing it after it after the fact.

“Agile/Lean movement” and Scrum in particular, made short cycles a key factor in the process. May it be cycles of planning, cycles of development or cycles of releases, there was a big arrow pointing at *short cycles* to figure out how to get more accurate, more responsive, more productive faster.

Due to the short cycles, the Features or “Product Backlog Item”, sometimes, just didn’t fit in. “My 2 months Feature won’t enter our 2 weeks Sprint!”. Because Sprint is, wrongfully in my opinion, being highly tied to releases, it raised a need to allow breaking Feature to multiple Sprints. The question is “how to break it right?”.

User Stories came to offer a methodology to assist in this need. The idea is to detail the Feature in multiple end-to-end flows (which good Feature already detail) and implement them one by one instead of trying to implement the entire Feature at once. Because User Stories are subset of a Feature, in the same language as a Feature, it felt that these stories can replace Features and Sprint will contain them as smaller execution parts. This will obviously “solve” the mismatch of Feature size to Sprint size.

I claim that it didn’t solve anything at the core level. Even worse, my feeling is that User Stories introduced a dangerous abstraction, one that should be used carefully. More on it in my next post...

Many confuse the terms Feature, User Story and Task. I believe it’s important to grasp the difference between them as each one serves different purpose and sometimes even different audience.

Feature

Feature is a detailed experience of how your users will do something with your application. In order to make “something” meaningful, a Feature must include (1) the reasoning behind it, the motivation, “the goal”, “the pain to solve” – without it, it’s simply impossible to judge Feature’s ROI in terms of value versus effort and money. Once this is in place, Feature should include (2) user flows. A user flow might be “User can click on the delete button to delete his record, this will popup [a message] for him to verify first”. Usually, a Feature will be built from multiple flows, edge-cases and wording to make sure the grand experience is fully complete. To help relating flow with look & feel, a Feature should (3) include mockups and other accessories. Lastly, (4) business (and even technical) notes should be added to wrap up the experience: URL structure, SEO considerations, user messages user, analytics requirements etc.

Language: customer’s lingo.
Estimation Size: Ideal Days / Story Points / T-Shirt sizes
Clients: Internal and external: development/marketing/business/analytics teams and also your customers (to share with them on feedback forums, blogs).
To Include: (1) reasoning (2) flows (3) mockups and (4) business/technical notes.

User Story

User Story is a single “user flow” from a Feature I described above. “User can enter his password and re-enter it for password verification. If the passwords are not matched, the system will show a message”. Another example: “User can enter his password; the system will check the password’s strength by [rules] and notify the user if the password is not strong enough”. By itself, from User Story is hard to understand the entire picture, but it’s a smaller unit of work to plan and execute by.

Language: customer’s lingo.
Estimation Size: Ideal Days / Story Points
Clients: mostly internal, sometimes external - some User Stories just don’t make sense on their own, without the Feature as complete background.
To Include: (1) flow (2) mockup and (3) business/technical notes.

Task

A task is a specific “todo” with a given work estimation. A Feature can be broken into multiple tasks and so does a User Story. A task will be something like “Add new column to database called Rate and model it in the application – 1 hour of effort”, or “create javascript function to validate input on price field – 1.5 hours of effort” or “create landing page for our campaign with Nike and connect it to our analytics system – 3 hours”. Task resolution will always be much smaller and much more technical than Feature or User Story. It will explain what to do rather than why.

Language: development/marketing/business lingo.
Estimation Size: Hours
Clients: internal only!
To Include: technical information needed.

As I mentioned, you should not tie sprints and releases together. I thought to add a few notes about what will make a Sprint Demo really great. Luckily Moran Haviv, our legendary Project Manager at Delver, wrote a great recap I thought to share with you:

Why Sprint Demo?

· The primary purpose of the Demo is to communicate, share and celebrate what everyone managed to do in the last sprint and what is the value of it for the user/Organization; In other words: what are we doing here and Why are we doing it?.

· Collect valuable feedback to make sure our users will love our product as much as we do!

· Teams gets to show off with their output/artifact to everyone; (even if the software has no UI it might yet deserve to be presented by a good story).

A few guidelines for preparing great demo

• Tell a story. Center your demo around a realistic user solving a real problem. The point is not just to show that the software works, but to show that it’s valuable.
• What is a good Story? Or How can you tell it :
  • Use a meaningful relevant theme;
  • Demonstrate sequence of events as the user would experience them (tell the story);
  • Use realistic data and characters—use examples and names from your user community or members of the development team;
  • Make it Exciting and Entertaining
• Keep it short. focus on what’s interesting and what’s valuable about your feature (you don’t need to exhaustively cover all your acceptance criteria).
• Prepare. Create any necessary test data.

Separation of Concerns

Working by the “scrum book”, sprint is also a release unit, in which you want to complete all the effort you committed to your clients and demonstrate it at the end of the sprint. Well, not in my book. Sprint should be remained an internal unit of time. Sprint is used for planning, for doing and for reflection, to make the team work better over time. It doesn’t mean that your customers will enjoy adjusting to your schedule.

I prefer to leave release cycles outside, as they are external unit of time. You need to adjust them to your customers, not the other way around.

Let’s say that you picked 3 weeks as a sprint size after considering “big enough, small enough” values. If you tie sprint and release together, that means that your clients will see things every 3 weeks. That might be fine, but it won’t allow you to challenge yourself to reduce release cycles. Even worst, the customers might demand a shorter release cycle to earn confidence in your delivery. A dangerous move, in my opinion, is to reduce the sprint size to match desired release cycle. This move might violate the “sprint should be big enough to avoid unacceptable overhead of planning/reflection” principle. Yes, your customers will be happy but your developers won’t. It won’t last. You want both internal team and external customers to be happy and enjoy a process that pushes them forward rather than pushes them around.

What is a Version?

Version is just a bunch of capabilities with a specific target date attached to it. Version is easy to communicate out: “we plan to allow a user to upload image, crop it and update his profile image in version 1.1, which is targeted to July 20th”. Basically, for each targeted date you specify a list of features, enhancements, reports etc. The customers gets to say when the versions should be aimed for, according to their needs.

What does it mean about Sprint Demo then?

Well, if the release cycles are shorter than sprint cycles then the Sprint Demo will become a show off by the team to each other rather to your customers. Obviously, you may want to add another “Release Demo” meeting for your customers (and maybe include the team in it). By doing Sprint Demo internally, the teams will get the chance to see what’s going on “on the other side of the corridor”. Oh, did I mention that this is also fun? It allows the organization to collect valuable internal feedback to make sure our users will love our product as much people who wrote it!

“Sprint” – what does it mean?

Note: my definition of sprint is not by the book. It’s perfectly fine by me as I love adjusting theory to practice; I hope it is okay with you as well. Basically, a sprint is just a time window that you plan to achieve something at. Just imagine a box with your interesting “todo” notes. For example, in the next 2 weeks you may want to plan to perform some proof of concept for your initiative; plan to create 3 landing pages to check which one covert users better to registered users; plan to write a tutorial or even plan to upgrade your team’s computers.

Why do I need to define a specific time window then?

The idea of a sprint, in essence, is simply to (1) ease psychological acceptance of changes and (2) allow shorter, just-in-time planning.

Specific time window, made constant (sprint after sprint), allows you to understand that things might change and you now made mental and physical “room” to adjust when needed. It’s a bit of sugarcoating, of course, but it’s making the transition smoother.

The just-in-time planning part is more “acceptable” when you’re embracing the fact that it’s too damn expensive trying to break all effort into small pieces. You’re customers are “allowed” to change their mind, so – what’s the point of understanding that something being requested for next year, will take 121 hours to develop? In 2 weeks, hell, in 2 days, this effort might cancelled. Breaking future effort to small pieces is great, but only if it’s extremely cheap to achieve or extremely relevant now. Until then, you might be okay with high level estimation.

The perfect size: big enough, small enough

Sprint should be big enough to (1) achieve meaningful progress and (2) avoid unacceptable overhead of planning + reflection. That means that if your smallest effort is always at least 1.5 weeks, don’t use 1 week sprint. If you need a full day to plan a sprint and another to reflect on how it went, don’t use 1 week sprint. Otherwise, your people might feel “we’re doing nothing but planning and reflecting”.

Sprint should also be small enough to allow to reflect and adjust often. Just like “release often” attitude, adjust often will make the organization work better, faster. Don’t dismiss it lightly.

How many sprints should I plan in details?

Good question if I may compliment myself for asking so. I would aim for detailed plan at least 1-1.5 months in advanced, unless you’re in a really volatile market and 1 month is “too far”. If your sprint size is 2 weeks, then I would say around 2-3 sprints. By saying “in details” I mean very detailed understanding of effort, real breakdown or very solid understanding, based on similar effort in the past or one-of-a-kind magic ball. The idea is to have good image of near future; this will obviously be expensive to create, but will give you confidence on how to achieve the most important goals on your table.

I would try to understand what’s coming later on (3-6 months), but invest much less time and stay with high level estimation. I don’t want to waste time on planning potentially irrelevant effort.

Natural dependencies planning

When sprint size picked wisely, there is much “smoother” feeling of dependencies planning. There is no real need for Gantt or something of that sort, thank God. Everyone will be aware of the effort being made in the sprint and will align dependencies accordingly. The feeling will be more natural, more just-in-time rather the stating “we need infrastructure team to finish in 6 months something so we could use it 9 months from now!”. It doesn’t mean that dependencies planning is gone out the window, you’ll still need to do so for big infrastructure effort, but you’ll see that it happens less than you were used to. This is a good thing.

Reflect and adjust

At the end of the sprint, it’s a great time to sit down and consider what went well, what wasn’t (take Action Items) and what can be done to have better sprint next time. You’ll adjust to external changes better when you’ll adjust to internal pains better.

I thought that Agile == no planning

Now, that is just sick. Seriously, no one is expecting you to work badly. Great planning is the only way to produce great products to your customers, deliver it on time and with high quality.

Not all planning are born equal

Accept it, plan accordingly :)

Delver is all about letting you to explore, research and (eventually) purchase products in a different way. Pushed and driven by what your network has to say, it will be easy for you to see what books your friends recommending, what kind of movies are hot or which camera you should buy next. You could publish polls, to get help from your friends on what to purchase, you can rate products and write reviews, you can create a catalog of items (“My ski trip to Italy”), create a gift catalog and share it with your other friends, recommend products to your friends and plenty more!

You’re more than welcome to check it out at http://delver.com/

We are still in “closed beta”, which means you need an *invite* to get in. Once you’re in, you can send invites to your friends and enjoy their feedback on items you’re interested at. If you want an invite, drop me a line with your email (or email me directly).

I’ve spent around 2 hours to figure it out, so at least I’ll write it down.
I’m using dotTrace 3.1 to do some analysis for .net web application running on Windows Server 2008 R2 (IIS 7.5).

I got strange numbers and was missing some data (methods calls) running “profile web application” until I set the affinity of the w3wp.exe process to single Node (single core). This can be done easily by opening the Tasks Manager, right click on w3wp process –> Set Affinity –> pick just one core.

Only then you should record the required page(s) and take the snapshot.

During team’s growth, the practice of keeping the knowledge base sound, looks like mission impossible. There are simply too many concerns to write down and maintain: picking a proper (=”searchable”) title to the knowledge base item, keeping the history of changes in the design and why they were made, adding some drawing etc. Text notes (and pretty pictures), what can we do, are getting obsolete extremely fast.

“How can we keep the team’s knowledge base without running after our tail?”

My team came up with this suggestion:

“Let’s keep the titles and put owners next to it, the rest can be solved with good communication and tests!”

Examples for such “knowledge base items” are, from our real list:

• Supporting Contextual Sign-In scenarios (Avish)
• Common CSS Classes for our beautiful look-and-feel (Moran)
• Creating and using pretty-URL routes (Ken)
• …

We broke it into domains like “basic architecture”, “common features”, “cross-cutting concerns”. Now the list is easy to search at (wiki) and fun to maintain.

This work extremely well if:

• Code-reviews are done on a regular basis. This means that at least 2 developers can talk about each knowledge base item.
• Tests are written to built great confidence (to refactor easily) in the code. I talk about unit-testing, integration testing, UI testing etc.
  • Great tests explain how to use the API and what should be expected from it.
  • Tests (mostly integration tests) explain the latest architecture.
• Comments in code should include the “why” behind the logic. Team members can add to it even more if needed, by talking with each other.
• New developers are exposed to the knowledge base, talking with the relevant owners. This is a great reference to look at.

Simple, short, effective!

Great dishes. Great timing. Every single day. This is one amazing place to eat at!

In many ways, running a great team of developers is just like running top-quality kitchen.
You’re measured by your ability to serve great quality(CI? well tested?), super tasty(nice UI?) dishes (features?), to hungry people (clients?) in reasonable time (before they’ll leave to another site).

Without solid understanding of ETA, there is no way to predict quality and release in time.

Most of us are driven by what life has to throw on us, may it be some personal event, a new book you read that makes you want to refactor everything or simply a lot of context-switches between projects and bugs.
Add this to our constant urge to excel at what we do, and you get a “miraculous” skill of losing control over our time. We’re built this way. Life is pushing us around!

How does this effect us or the “wheel” I’m talking about? I want to introduce you to Joe. 
Joe is a nice guy in my imaginary world, working as a superstar developer for “TheBestOutThere” company. Joe was assigned to complete a feature and asked to estimate when it will be done. “This feature is quite simple”, he shoots fast, “a few changes here, a few there and then the UI to nail the all thing. Hmmm… I guess that no more than 2 days of work”. So our story begins…

The first day goes pretty well as Joe adding the needed fields to the database and even manage to complete some tasks regarding the logic needed. On the second day (reminder: the last day according to the ETA) things starting to bite Joe’s ass. The feature turns to be a bit more difficult than he anticipated, and he feels that it will take 2 extra hours to complete the work. Keeping it in mind, he already notifies the wife he’s going to be late today. “Damn, late again?”, he ponders, “oh well, at least I know what is left to do now”. Knowing that he needs to leave late today, he continues to work and suddenly he detects a really ugly piece of code in his path. “Refactoring time baby!”, he smiles to himself. “Well, I already have a few spare hours, why not?”, he convince himself once more. It works. The refactoring takes additional 4 hours. Joe, in a panic attack understands that it took more than he planned, hurries up missing a few critical tests and canceling the “code review” meeting claiming “this feature is simple enough!”. The code-review still takes place as this is simply a must for top-quality kitchens. Fixing the code review comments, including adding the missing tests (as needed to begin with) cost a few more hours and so days starting to fly by. After 5 days, Joe moving the feature to “code-ready”, now waiting for QA to test the feature. QA opens about 7 bugs, which take 6 more hours to fix (with solid unit tests to reproduce these bugs). On top of it, some more fixes were needed for easy deployment later on in production. The feature took total of about 7 days. Where is the missing 5 days went to? is Joe simply a poor estimator? Not quite, he just suffer from bad “context” we all do. He suffers from the constant battle between deliver fast and deliver with high quality. The problem is that it’s really hard to understand how estimation and quality work together.

If ETA is Jesus, Quality is God. Which is more tangible?

People are wasting time trying to convince themselves they can outperform on a daily basis. We can’t. Our best is probably not as great as we imagine. Instead, let’s not try to improve our ability to code faster, think faster or drink more coffee. Even if you manage to get better at it (or consume more coffee and urinate to a cup), it won’t last for long (urine tends to stink in the room).

Instead, think carefully about “where the hack my 5 more days went to? Could I see it coming?”
Here is the “context” Joe needed to have in order to produce a complete feature, with great quality, in time:

1. Did I spare enough time reading the spec and talking with the Product Manager about it? (yes, this is part of the feature!)
2. Did I make sure there are no open issues left?
3. Did I spare time thinking about how this feature will be tested? how we can automate these tests easily?
4. Did I spare time to design the solution and do the required review with other people? what about the hours needed to fix your solution based on the reviews?
5. Did I spare time to read QA test cases and give feedback on it?
6. Do I have everything you need to make the feature a huge success?
1. What about people helping you out where needed?
7. Did I spare enough time to write the code itself? are you sure?
8. Did I spare time for testing? I talk about really great testing (unit tests, integration tests, automated UI tests, manual UI tests)
1. Again, the goal here is great confidence in quality, not 100% test coverage.
9. Did I spare time for code reviews? for code reviews fixes?
10. Did I spare time thinking about how this feature will be deployed?
11. Did I spare time sitting with the Product Manager again on your final result before merging your work back to “trunk”? (do it now as it’s “hot”)
12. Did I spare time for “bug fixing buffer” (saving ~10% of the feature time for bug fixing is a good start, try to reduce later)?

Estimating each one of these steps (use “buffers” if certainty is low) and you’re a bit closer to understand where the missing 5 days vanished. 
Joe was thinking only about the coding effort, not the entire picture! This, by nature, means inability to consistently predict when something will end. He was pricing the wrong thing!

What does it take to make your team great unit of brilliant minds producing great dishes, every time:

1. Hire the best. They simply worth it. (oh well, that was easy, right? :))
2. Trust them doing the best work one can do! Help them get them but don’t think they can’t get there by themselves with the right set of tools and context.
3. Start with explaining the meaning of great ETA - without it, prediction is impossible. Consistency is a lost cause. This is one bad kitchen.
4. Ask people to stand behind there ETA. They are responsible for it!
5. In the same breath, remind them that quality work is the right path to get a correct ETA. Quality work will lead to shorter cycle eventually!
6. But (here comes to tricky part!), they should also remember that over-refactoring leads to high quality of nothing important (as nothing really reach production).
7. So, define together what is “quality work”. Set it as “team context”.
8. Constantly hear what your guys has to say about “I wish we could fix it!”. Eliminate the big things (lack of tools, too many context-switches, not enough testing etc).
9. Try to inject a lot of honesty, communication and great motivation to the team. This is the basic engine oil no one can live without.
10. Measure delivery cycle length: spec –> design –> getting ETA –> feature is code-ready –> solving all bugs –> deployed in production.
11. Talk with your guys to understand waste again. Eliminate the big things now! seriously!
12. Keep hiring more people, only the best, you’ll need them soon enough.

Over time, the cycle of delivery should get much better while the quality will get even higher. The trick here is that people will feel more confident in the flow, “saving'” time to write quality piece of code, making features amazingly stable in the 1st attempt. This is the consistent rhythm you should dream of. The wheel spins…

Can you count the number of times you were asked with this innocent question?

I tried to think and analyze the "motivation" behind this question, considering why people are so intrigued to hear my answer when putting me on the spot. Is it really that important for others to know what Oren have to say about God? I can't ignore the simple fact that religion is a huge cornerstone in our life and finding more people with similar believes give us great comfort and sense of power. People are looking for acceptance, to become part of a group they can define and feel "right" in. This is a social aspect that is common to almost everything we do in life (love, friends, work, faith etc). I already know all of that and so do you. So, where am I going with this?

I'm trying to muse with the the notion of acceptance and where do I fit in. What is my "do you believe in God" question?

Personally, It's striking me as plain crazy that our life is so driven to into what I grasp as the "wrong" groups. Do you believe in God? Do you eat Kosher food? Do you fast at Yom Kipor? Are you rightist? And the list goes on and on. Are these the questions we should really ask ourselves? is these how we want to measure ourselves or find others to connect with? I'm not sure I know the answers, but I feel there are some deep feelings, clear ideas and emotional borders that I'm so passionate about, they must represent my scales. They must represent my inner truth. Writing allow one to shoot ideas and thoughts on paper, so I tried to explain myself my truths. Hopefully it will give me a common ground to fit myself into a world I truly believe in and measure myself about what I see as right. Trying to synthesize my list, I came up with the 3 questions I have definite feeling of, (but) these are only my big questions so read it with the appropriate suspicion:

1. Are you making someone else proud?
   I'm blessed with the best parents one can wish for and the greatest family one can be born into. The best thing they have done for me is giving me their complete trust, always stating how much faith they have in me making the right call. It was really hard for me to mess things up with that kind of love and support. Make sure that you've got someone in life that you can make them proud, may it be your parents, family, girlfriend, close friend or the girl from the cafeteria. "I'm proud of you" is huge empowerment and it's a constant motivator to drive your life beyond the easy and all-so-common mediocrity. This source should be your impregnable place for positive enforcement, keeping you down to earth and posses the right confident to make tough choices in life.
   
   Be careful not to confuse making one proud with making one satisfied. You must own your path thus there is no place for blind acceptance. You need someone that trust your best efforts and push you forward in your struggles.
   
   
2. Do you see yourself as a good person?
   Let's avoid the definition of good for a second as it doesn't really matter. Although some of us really cynical about the meaning (and with no doubt some are plain bad), we all know that Mother Teresa is a good soul. The pure notion of bad and good is embedded deep inside us. Try to be truthful to yourself, do you see yourself as a good person? how would you define good? Do you think you can measure "how good" are you? Do you think it's important? Are you doing what it takes to get "better"? does it get easier to look at the mirror?
   
   You can call me what ever you might feel, but there is a romantic notion behind "being good". The way I see it, my time here is limited so my constant question is "what am I going to leave behind?". I would like to think that I've touched some people during my short life, that I managed to teach something as my great family and friends have taught me. I'm not sure that I made a great change (or even a small one), but at least I feel I did the best I can do with my believe of sincere communication. I'll never be Mother Teresa, but at least I'll do the best I can with what I feel is right for me, trying to focus on my strength and talent to make others picking their brain and wonder about themselves. Being there for others will make you feel less alone, less "on a road to nowhere". What do you have to lose?
   
   
3. Is there a way for you to help others?
   Do you feel lucky? If you do, you played your cards right somehow. Is there a way for you to show your tricks to the world? to make others think of a different way to look at things? Helping others makes a great closure between making others proud and making you feel as a good person. It's a powerful tool you should use wisely. The purpose is not the "convert" someone into your believes or trying to bring him into your "group". One should reach his own right and wrong, you can only help him by asking the right questions and trying to share your thoughts and experience. This way you are part of the journey, part of a legacy in other's life. This is a great accomplishment to leave behind you.
   

The order of the questions is important. Without making others proud and have their support it's impossible to be highly motivated all the time. Without constant motivation you won't allow yourself to grow into the person you can become, making it easier to avoid helping others and seeking for the "wrong kind" of acceptance. Giving up is easy, fitting in just for the sake of acceptance will not make you happier (at least for long).

Don't allow yourself to give up just because you were born to the wrong environment, that you had troubles as a child or you feel just like the world is against you. The world don't owe you anything, you can blame your luck, your God (or lack of it) but bottom line it's really up to you. Don't hurt others to pay back to your awful sense of luck. Find your positive people around you and let them pick you up when needed, there is no shame of needing others help, they would love to do so in order to feel good about themselves and making others proud. You'll do the same for them one day, I promise you that.

Everyone who knows me are familiar with my reiterative phrase "I firmly believe in natural growth", this rule apply here as well. Find your own sources of strength and make sure that you keep your "good standards" before trying to influence others to ponder about their path in life. Once you have the confidence in your answers, you'll be ready to open your view to the world and see what it has to offer.

Do I believe in God?
We're probably ants in a giants world, but is it really matter? I would like to think that this God cares more about us as living being, trying to grow together than following strict rules without understanding the real truth behind them. Isn't this the all purpose of the bible? of the stories we are taught since we were born? I wish our discussions would address more of the "are we doing the best we can?" and "how can we make it better?" rather than such a superficial scratch of our real purpose.

I would love to hear what is your truth and which questions drive you in your path. Drop me a comment if you feel like sharing.

Ron challenged me to write my own implementation of reader/writers lock. He did a great job of doing his own implementation.

I came up with this:
(note: this is really naive implementation, it's far from ideal in terms of fairness and possible racing conditions. Just take it as brain-teaser)

   1: public class StateReaderWriterLock : IDisposable

   2:     {

   3:         private readonly AutoResetEvent _changeStateAutoLock = new AutoResetEvent(false);

   4:         private readonly AutoResetEvent _writerDone = new AutoResetEvent(false);

   5:         private readonly object _readersLock = new object();

   6:         private readonly object _writersLock = new object();

   7:         private int _readers;

   8:         private int _state; // 0 is "neutral", 1 is read, 2 is write

   9:         private int _writers; 

  10:  

  11:         public void LockReader()

  12:         {

  13:             while (true)

  14:             {

  15:                 // try to bring the state from "neutral" or "read" to "read". If the current state is "write", let's wait.

  16:                 while (Interlocked.CompareExchange(ref _state, 1, 0) == 2)

  17:                     _changeStateAutoLock.WaitOne(); 

  18:  

  19:                 // an interesting case here where the last reader is now in ReleaseRead and we're trying to read as well, we might be too late (the writer might have changed the _state already)

  20:                 // if that happens - we're back to square one, but we still want to avoid recursive locking!

  21:                 bool loseInRace = false;

  22:                 lock (_readersLock)

  23:                 {

  24:                     if (Interlocked.CompareExchange(ref _state, 1, 0) == 2)

  25:                         loseInRace = true;

  26:                     else

  27:                         _readers++;

  28:                 }

  29:                 if (!loseInRace)

  30:                     return; // success!

  31:             }

  32:         } 

  33:  

  34:         public void ReleaseReader()

  35:         {

  36:             lock (_readersLock)

  37:             {

  38:                 _readers--; 

  39:  

  40:                 // if I am the last reader, let's reset the state so any given reader/writer can take it

  41:                 if (_readers == 0)

  42:                 {

  43:                     Thread.VolatileWrite(ref _state, 0);

  44:                     _changeStateAutoLock.Set();

  45:                 }

  46:             }

  47:         } 

  48:  

  49:         public void LockWriter()

  50:         {

  51:             while (true)

  52:             {

  53:                 // try to bring the state from "neutral" or "write" to "write". If the current state is "read", let's wait.

  54:                 while (Interlocked.CompareExchange(ref _state, 2, 0) == 1)

  55:                     _changeStateAutoLock.WaitOne(); 

  56:  

  57:                 bool loseInRace = false;

  58:                 lock (_writersLock)

  59:                 {

  60:                     if (Interlocked.CompareExchange(ref _state, 2, 0) == 1)

  61:                         loseInRace = true;

  62:                     else

  63:                         _writers++;

  64:                 } 

  65:  

  66:                 if (!loseInRace)

  67:                     break; // great success!

  68:             } 

  69:  

  70:             // allow 1 writer only

  71:             if (Thread.VolatileRead(ref _writers) > 1)

  72:             {

  73:                 _writerDone.WaitOne();

  74:             }

  75:         } 

  76:  

  77:         public void ReleaseWriter()

  78:         {

  79:             lock (_writersLock)

  80:             {

  81:                 _writers--; 

  82:  

  83:                 // if I am the last writer, let's reset the state so any given reader/writer can take it

  84:                 if (_writers == 0)

  85:                 {

  86:                     Thread.VolatileWrite(ref _state, 0);

  87:                     _changeStateAutoLock.Set();

  88:                 }

  89:                 else

  90:                 {

  91:                     _writerDone.Set();

  92:                 }

  93:             }

  94:         } 

  95:  

  96:         public void Dispose()

  97:         {

  98:             _changeStateAutoLock.Close();

  99:             _writerDone.Close();

 100:         }

 101:     }

 102:  

Not sure it's the greatest job interview question, but it is indeed challenging and fun to play with.

Imagine you've got the following code, running in 2 separate threads T1 and T2:

private bool _go = true;

T1                                      T2
while (_go)                        // ... some code here ...
{                                         _go = false; // something happened, let's stop
   // ... do work
}

Even if T2 will set _go to false, this code might lead to endless loop in T1. Why is that?
Each CPU have a local memory called L1 Cache, that might cache the value of _go. Multiple threads running on multiple CPU's can (and will) cache data and re-order instructions to optimize code. So if for example, T1 is running on processorA and T2 is running on processorB, we might have an endless loop here. A simple solution here is to add the volatile keyword on the _go field definition to assure order and avoid caching on CPU level:

"The volatile modifier is usually used for a field that is accessed by multiple threads without using the lock statement to serialize access. Using the volatile modifier ensures that one thread retrieves the most up-to-date value written by another thread." (MSDN)

Now let's examine another example, again 2 threads T1 and T2:

private int _writers = 0;

T1                                                         T2
while (_writers > 1)                              ....
{                                                           Interlocked.Increment(ref _writers);
    _someAutoEvent.WaitOne();
}

You can see that we're using an atomic increment via Interlocked.Increment method, so we should be thread-safe here right? not quite.
We've got one thread that is reading (T1) and another thread that is writing (T2) to _writers. If T1 is running in processorA and T2 in processorB, the _writers value will be cached on the CPU level for some time which means T1 might see different value than T2. If T2 would have catch the returned value from Interlocked.Increment and it as the only reader of that field, then it was thread-safe. This is not the case here.
The solution here is to use Thread.VolatileRead(ref _writers) to make sure T1 gets the latest value. We could have used lock keyword as well of course to serialize access to _writers field.

Summary:

• Although setting a word size variable is atomic (like in our first example), it doesn't mean it is thread-safe! For "boolean flags" I would recommend using volatile as a clean and simple solution.
• For "counters scenarios", I would have used Interlocked with Thread.ReadVolatile. This should outperform lock usage and still keep your code neat and shiny.
• The lock keyword is probably the safest way to avoid dangerous race conditions, so unless you're sure about your solution, keep it simple and use lock.