Estimations in Agile development – Estimating the Backlog with Story Points

This is the second post in the Estimations in Agile development series.

Epics, User Stories and Tasks

Estimating User Stories with Story Points (you are here)

Sprint Planning Methods: Capacity vs. Velocity vs. Feature

Improving Estimations using Burndown, Burnup and Actual time metrics
In the previous post I’ve introduced the different product backlog items, their hierarchy and scope.
In this post we’ll learn how to estimate user stories using story points. I’ve introduced the videos website project that I’m building. This is its current epics backlog:

Story points
We need to estimate those epics, but how? The trivial option is time. We usually estimate effort in time “It takes two hours to get to Tel Aviv”, “The renovations will be over in a week”. However, it is extremely hard to estimate long term effort in time.
Let’s look at the first epic Allow users to find, play and comment on videos. This is obviously a lot of work. It is more than a week and probably less than a year. Every time driven estimation won’t be accurate. It is hard to estimate accurately something that is longer than a week. Months? Impossible. We need something else.
When estimating long term effort we should use a more relative unit like size or complexity.
These units allow us to easily compare features by their size or complexity. “This one is 2 times bigger/more complicated than this one”. It allows to easily separate the complex features from the easy features or from the small ones to the large features.
Since the units are relative to one another we can choose any numeric representation that we want. We only have to stay consistent while using it.
It can be 1,2,3 story points when 1 is super easy and 2 is harder, or 10, 20, 30… . It doesn’t really matter and that is the beauty in story points. Personally I prefer reflecting size in story points. “How long does it take to get from Tel Aviv to Herzelia? Same as getting from Tel Aviv to Holon which is 2 (some relative representation of this size)”.
Another option is ideal days. “How many days will it take if the days have absolutely no distractions?” The problem in this way is that yet again it is time based and we suck in estimating long term in any time based method. Hence it is not recommended.
Prioritize, estimate and prioritize again
The backlog will be constantly prioritized and changed due to business requirement, estimations and new discoveries along the way.
In order to properly prioritize we need to have the business prioritization along with the estimated R&D effort. Usually it will take 3 rounds:

1. The first one is a “business prioritization” round. The product manager will prioritize the epics based on their business values. What feature does the user must have first?
2. The second round is a “technical effort estimation” round. The R&D will go through the list of epics and spot the ones with the highest level of uncertainty and risks. We don’t want to leave the unknowns to the end – we want to tackle them from the beginning in order to increase our level of certainty in the required effort. Unknown effort usually is a big effort, hence its story points value will be big.The recommendations epic has many uncertainties like introducing intersects into the system and understanding what videos the user will actually want to watch. It seems like it is 3 times bigger effort than the other two epics. We’ll estimate it with a value of 30 while the other epics are 10. The cool part is that it doesn’t have to be “3 times bigger” it can be 5 or 10 times bigger. It is relative. It means that a new epic will have an estimation that is relative to the previous ones: is it “more like” the big one (30) or more like the first one (10).
3. The third and last one is the “business prioritization” round again. This time the product manager sees the required effort for all the epics and decides whether some of the highly estimated epics should be moved higher or lower in the backlog. Perhaps if a feature is so difficult to implement then it shouldn’t be implemented at all. Our product manager is fine with our estimations and he decides to leave the epic in its current priority. The first two are more valuable than the recommendations.

This is our current estimated backlog:

Estimating User Stories
The epics are prioritized and estimated. Now what? We can start all the epics simultaneously but then it will take us much longer to finish the first one as opposed to focusing only on the first epic. Keep in mind that every epic has a real value to the user hence we want to decrease the time to market of every epic. In order to achieve that we must strive to start only a single epic at a time. There is a great phrase that one of my managers used to tell “stop starting – start finishing”. We should strive to focus on the most important feature first. Finish it and only then move to the next one. The feedback that we’ll get from real users might change our initial priorities.
Now it’s time to split the first epic to user stories. We’ve done it already in the previous post:

The estimation process of user stories is identical to the epics. User stories also give actual value to the user, hence we need to deliver the feature with the most value first. Watching videos in a video library application is probably more important than commenting or searching (without videos to search or comment on).
Now it is time for technical estimations round using story points – same as before. In this case the first user story is bigger than the other two since this is the first feature. We need to build the application’s first screens, create the project, build continuous deployment (hell yeah! From the start) and allow to actually watch videos.

*If you try to add up the estimations you won’t reach 10. That’s alright since 2 SP and 1 SP are not equal to 3 SP. In the next posts we’ll talk about ways to sum estimated effort in a more precise way.
The filter user story has the smallest estimation since it has no persistence complexity and it feels like less effort than the other features.
If a user story receives a big estimation then it is a sign that we don’t understand it well enough or perhaps it is just too big as a single feature. In both cases the best practice is to split it to 2 or more user stories while every user story will give actual value to the user. That is exactly what I meant in my previous post when I mentioned that epics split to themes and only then to user stories. Since this is our first estimations round we still don’t know what a too big estimation is. In the next post we’ll learn how to define our limit and by doing so define when we should break the user story further more.
Time for the last business round of prioritization. This round is the most important one since it determines the next feature that the R&D will work on and that the user will see.
After we’ll complete it and deliver it to the user we’ll receive feedback that might change these priorities. This is good. Our job is to deliver what the user wants. Having a real product at his hands might change some of his first assumptions. This is why the prioritization will happen again and again. Along with the priorities the estimations will also change. Something that we thought was 2 S.P. appeared to be much easier or much harder and it is no longer should be like other 2 S.P. user stories. It may sound depressing to constantly re-prioritize and re-estimate the backlog, however, this is the only way it will truly reflect the product.


Starting the sprint
We know the user story that we should work meaning we are ready to start our sprint. The sprint starts with a “sprint planning meeting”. In this meeting the team splits the user story to technical tasks and estimates them.
Should we also use story points for estimating tasks?
How do we know that we filled our team’s capacity?
What is capacity?
How do we improve our estimations?
All that and more in the next post.
 
Estimations in Agile development – Epics, User Stories and Tasks
Estimations in Agile development – Estimating User Stories with Story Points (you are here)
Estimations in Agile development – Sprint Planning Methods: Capacity vs. Velocity vs. Feature  (go here)
Estimations in Agile development - Improving Estimations using Burndown, Burnup and Actual time metrics

This is what I read

I read a lot. I think that reading is one of most important activities one can do in order to improve and become better.

I share most of what I read on my Twitter account. Recently more and more people ask me where I find the stuff I read. So I decided to share with you my sources.

There are 5 main sources where I constantly find great articles, videos and posts:

1. Feedly – here I keep my blog roll (you can find the full list in the end of this post). It is a simple RSS reader where I subscribe to the blogs that are the most relevant to me and which I want to be up to date with their content. if I land on a good post in an unfamiliar blog, I go through the last 3-4 posts and if most of the content is actually good and relevant, then I add the blog to Feedly.

2. Twitter – unlike Facebook, that is full of my friends posts (and pictures), in Twitter I follow business newspapers, tech news, engineering content, leading CEO’s and tech world “celebrities”.

Netanel Lev wrote once a post describing the difference between Twitter and Google Reader (like Feedly) - Twitter is my radio station, Google Reader is my disc player! This post describes perfectly the difference between a RSS reader that has predictable content that you have chosen like music on a CD (Yes I know, that is an old post ). And Twitter, that is unpredictable and “every new tweet is a song that maybe I like or not”.

3. Pocket recommendations – Pocket is my favorite and most used app. I keep there everything I find interesting, in order to read it later, when I have time. Another cool Pocket feature is a recommendations feed that is created by different members of the Pocket community (the content that they recommend to others, and by Pocket itself using personalization mechanisms). The more you read the better recommendations Pocket will provide for you.

4. Software Lead Weekly – this is a weekly mailing list created by Oren Ellenbogen. It aggregates great articles and videos regarding tech, leadership, startups and engineering culture.

5. Books! Posts, articles, videos, tweets are great way to learn new things and be updated with what happens in the world. However, if you wish to master something and become a true expert you have to read books. A post by some expert can get you this far, but a whole book that is written by that same expert will teach you whole lot more. This post has a list of 95 books in various topics that are probably relevant to you. This is a great place to start building your library.

I think that you should have at least 2 sources (besides reading books):

(1) A blog roll that you have picked based on your interests (you can use any RSS reader, Feedly is my choice).

(2) “An unpredictable radio” – Twitter, Pocket, Medium and more in order to be exposed to new sources and things you didn’t know that exist.

Keep reading!

 

As promised here is my blog roll:

.NET

1. http://dailydotnettips.com/ - Short posts of great tips in .NET and Visual Studio

2. https://visualstudiomagazine.com/Home.aspx - .NET news

3. https://shonnlyga.wordpress.com/ - a friend of mine who writes about .NET related stuff

4. http://www.dotnetrocks.com/ (podcast)  - no need to listen to all of the episodes – pick the ones that you feel are relevant to you

5. https://codeblog.jonskeet.uk/

6. https://ayende.com/blog/ - Oren Eini, one of the best developers in Israel (some say that in the world). He used to write about .NET low level stuff but now most of his posts are about RavenDB (his product - .NET based DB), Sometimes he shares some bugs that they had and more interesting stuff

7. https://visualstudiomagazine.com/rss-feeds/blogs.aspx - Visual studio blog posts

8. https://visualstudiomagazine.com/rss-feeds/news.aspx - Visual Studio news

9. https://blogs.msdn.microsoft.com/dotnet . NET announcements

10. http://visualstudiomagazine.com/rss-feeds/features.aspx -new features in the NET world

Architecture:

1. https://lostechies.com/ a blog with several great writers: the creator of AutoMapper, CQRS and event Sourcing experts and more

2. http://martinfowler.com/ - The one and only Martin Fowler.

3. http://www.aviransplace.com/ - Head of WIX backend. He writes about software solutions, architecture and management

4. http://www.softwarearchiblog.com/ - The best Israeli Hebrew blog.

5. http://enterprisecraftsmanship.com/

UX:

1. http://uxi.org.il/

Tech stuff:

1. http://www.hanselman.com/blog/ - Scott Hanselman’s blog

2. http://www.hanselminutes.com/ - Scott Hanselman’s podcast

3. https://thefutureorganization.com/ - Hebrew Tech podcast. My favourite episodes are “Bumpers” – one hour of 2-3 minutes short discussion about variety of technology topics like frameworks, tools, announcements , posts and more 

4. http://blog.house-of-code.com/ - Yossi Shmueli’s blog

Culture:

1. http://blog.crisp.se/ - Used to work in Spotify and now in Lego!! Greatposts about agile, lean and culture

2. http://www.joelonsoftware.com/ - Joel Spolsky the creator of Stack Overflow and Trello. Worth following him on Twitter.

3. http://blog.karmona.com/ - Moti Karmona’s blog

4. https://blog.8thlight.com/ - culture and leadership – software oriented

5. http://www.mngttips.com/ - Hebrew podcast about management

6. http://shavua.net/ - The BEST Hebrew podcast! It’s about startups. They interview the biggest Israeli CEO’s, CTO’s and enterpanures about their startups success or failure.

7. https://thefutureorganization.com/ - Podcast regarding the culture in different organizations and startups

8. https://lnetanel.com/ - Netanel Lev’s blog

9. https://medium.com/@rabashani/ - Shani Raba’s blog

10. http://randsinrepose.com/

11. http://www.timeninjablog.com/ – time management tips

12. https://apakash.wordpress.com/ Alon Pakash’s blog

Web:

1. https://fivejs.codeschool.com/ - 10 minutes podcast episodes about the latest libraries and feature in JS.

2. https://internet-israel.com/ - Hebrew blog

Tech companies blogs:

1. http://blog.wix.engineering/ - Wix blog

2. https://code.facebook.com/ - Facebook blog - Priceless!!!!

3. https://labs.spotify.com/ - Spotify

4. http://nerds.airbnb.com/ - Airbnb

5. https://baremetrics.com/

6. https://blog.twitter.com/ - Twitter

7. http://githubengineering.com/ - Github

8. http://engineering.instagram.com/ - Instagram

9. https://engineering.pinterest.com/blog/rss - Pinterest

10. http://techblog.netflix.com/ - Netflix

The Project of Your Life

By settings personal goals we improve ourselves and become better. I use Lean and Scrum principles for creating and tracking my personal goals.

Keep reading and see how it works.

 

When working on some project we set milestones, long term goals, short term goals and KPIs.

We track progress and learn from our work by having retrospective meetings and checkpoints along the way.

Now imagine you have a very large project ahead of you and you don’t plan at all. You just float and react to the different events along the way. Do you think you can make it right? On time? On budget? The answer, like always, is “it depends”. However, it’s more likely that you won’t.

In order to succeed, we need to manage our life and not be managed by it. You need to manage it exactly like you would manage that project.

Your life is a project and you are its developer, designer and product manager

How many times did you say to yourself that you need to be better in this and that you should learn that? How many of those goals have you actually accomplished?

The first step is to define what you want. I personally like this article. It makes me think about my strengths, weaknesses and just the things I want to know. I have a dedicated time every six months when I go over these questions and create my long term goals. These goals are the things I want to accomplish in order to be successful and better than I am today. I keep them in my Google Keep notes.

*These are my personal goals:

Every personal (and not just personal) goal should be well defined (SMART goal).

Specific – Your goal definition should answer these questions: Who is involved? What do I want to accomplish? When?
Measurable – How can you measure progress and know if you are done?
Attainable – How can this goal come true?
Realistic – Be honest with yourself. Don’t define unreachable goals.
Timely – Provide a time frame. Then, creating 6 month goals, you are ready to do it.

Breaking Down Long-term Goals to Short-term Goals

Defining long term goals is the first step in improving. Setting a goal is better than setting no goals at all. Writing it down is a commitment to yourself.

In order to accomplish a long-term goal, which is usually a big goal (I want to master JavaScript, etc.), we need to break it down to smaller pieces – smaller goals (milestones) that we’ll accomplish along the way. Those goals should also be SMART goals. I have a recurring monthly time when I go over my long-term goals and decide what I want to do this month in order to get closer to accomplishing the whole goal. Like in Lean development, I constantly adopt and change my goals according to the situation (Perhaps there is no reason why I should learn JavaScript anymore?).

The monthly short-term goals don’t always have to correlate to the long-term goals. Perhaps I want to take care of something in my job or maybe learn something that is not part of my long-term goals and is important for the following month. To be honest, it doesn’t really matter. As long as you take time to think about it, take a decision and commit to it by writing it down you will improve and be better. That is the whole point.

If you have never tried to “manage” your life and set goals for yourself, then I suggest you start with monthly goals. Think about the month ahead of you and try to define how this month will become a successful one.

If you have set personal goals before, then I suggest you take it further.

A month is a lot of time – four whole weeks! Usually when we have so much time ahead of us, we won’t start any task until the very end-and that is only if someone reminds us about it in the first place. That’s called the student syndrome.

Weekly and Daily goals

Scrum uses sprints in order to prevent the student syndrome. I like to look on my weeks as sprints. Every week has a sprint planning and a retro. I go over the previous week’s calendar and see how it went. I try to find the things I need to be better in and the things  I need to preserve and keep doing. This way I can improve and track my progress weekly. At the beginning of the week I have a dedicated time for planning my weekly goals which are subsets of my monthly goals, and the tasks I need to accomplish this week regardless of any long-/short-term goal.

During the week I have a “daily standup meeting” (although I do it on the train on my way to work) using Any.DO. This has a very cool feature that at 08:00 makes me go over my daily tasks and decide when I want to do them (sometime today or later this week).

It is simply a to-do list that reminds me of the tasks I need to accomplish every day.

Every week ends with a retro. I go over my previous week and write down important notes, facts and decisions. I write them in Penzu, which is basically a diary with a very cool feature –every week it sends me the note I wrote a year ago. This way, I’m constantly being reminded of my decisions (you need to use it for a year in order for it to be effective - don’t give up!).

Summary

If you want to improve, you need to set personal goals.

The goals should be both long- and short-term.

Track both of them in Google Keep.

Every week, set yourself weekly goals and have e retro for the previous week. Write it down in Penzu and be reminded of it afterwards.

Have a daily meeting using Any.Do.

 

 

This works for me, perhaps it can also work for you.

Or maybe I’m just crazy

 

Acknowledgments:

Netanel Lev and Shani Raba for reviewing the post.

Estimations in Agile development – Epics, User Stories and Tasks

Agile, scrum, Kanban and Lean are no longer “new” methods for software development. There are hundreds of articles, books and courses about them. However, most of them include introduction material that mainly focuses on the basics. If you actually start using one of these methodologies you’ll quickly ask yourself with a missing – how are you supposed to estimate your work?
If you search the web you will see that there is not much data about estimations, simply because it is HARD. It is very hard to estimate correctly. Jeff bezos used to say “If you are planning for more than twenty minutes ahead in this kind of environment, you are wasting your time”. We cannot predict the future, but we can maximize our chances in getting as close as possible to it.
After reading several agile books (e.g. Agile Estimating and Planning by Mike Cohn), scrum courses and 6 years of practicing Scrum and Kanban in various projects I’ll try to add that missing piece called estimations in Agile development.
This is the first of 4 posts in the “Agile Estimations” series.

1. Epics, User Stories and Tasks (you are here)
2. Estimating User Stories with Story Points
3. Sprint Planning Methods: Capacity vs. Velocity vs. Feature
4. Improving Estimations using Burndown, Burnup and Actual time metrics

This series is not an introduction to Scrum. Before you keep reading, you should be familiar with the agile manifesto and Scrum in general. There is no “right” way to do Agile. You should change it so that it fits your needs. However, it is very important to understand the root principles and evolve from them.
Making the series practical
In order for this entire series to be practical and not just theoretical we’ll apply the content on a Youtube like application that I’m building right now. It should allow users to upload and watch videos. It should allow users to edit their videos details and rate others videos. It should have search, tags and filters (top seen, recently added and more). It also should recommend different users videos that matches their interests.
Let’s start
Before we jump to the different approaches regarding estimations let’s first understand what is it that we need to estimate. A project’s specification evolves with time. It starts with large and unknown features requests and eventually transforms to some tiny and technical tasks. In this post we’ll understand how this transformation does happen and why.
It is not just User Stories
Everybody knows that in Scrum and most of the other agile methodologies you must have a board and some sticky notes on it.

*Maybe your board is not a physical board but it is still a board. With notes.
What are those notes? They are the actual work that is currently being done. The actual tasks that the team is working on in order to accomplish some user stories. User stories represent the user’s need. A feature that should be added to the application that will gain the user value. The tasks are the technical representation of that need.
A user story represents a feature. However sometimes that feature doesn’t stand on its own or it is part of some bigger feature or a business concept that incorporates several features. That is called an Epic.
Epic
An epic is the biggest representation of a feature. In order to deliver an epic to the user we must divide the epic to smaller pieces – user stories.
*In the Agile books epic is not divided directly to user stories it first divides to something that is called “Themes” and only they are divided to “User Stories”. However in the last 6 years I have never seen any team that uses Themes therefore we’ll not use them either.
In our application we have three epics:

1. Allow users to find, play and comment on videos
2. Allow users to upload and edit content
3. Recommend videos to users based on their interests

This is our current product backlog. A backlog is basically a list of features that represents all the user’s needs and wishes. The backlog has two main principles that we should always apply:
1. The backlog must always be prioritized from high to low according to the user’s needs.
2. Every backlog item must have a “DoD” – Definition of Done that defines when the feature is actually complete. Sometimes it is called “Acceptance criteria”. It doesn’t replace the full description of the feature or its design. It is only a single sentence (maybe a couple) that describes how the feature will behave in the end.
Our backlog is already prioritized so let’s add DoD to the epics.



*there are many agile management tools out there. You don’t have to use them, a physical board and sticky notes can be enough. However, when working on big project a dedicated virtual tool might be really useful. I personally recommend on Visual Studio Team Services.
Remember that the epics should not include any technical or implementation details. They should only describe the business value. A more detailed description will be found inside the epic’s user stories.
By prioritizing the backlog we know what is the most important feature that the user needs, hence it will be developed first. After we’ll finish it we’ll move to the next one in the list. This way we always deliver the user what he wants the most.
I think that this is one of the best concepts in Agile development that is so different from the traditional ones. This way we can deliver small and valuable features to the user and receive feedback along the way.
Breaking Epics into User Stories
So the first epic is “Allow users to find and play videos”. In order to get a better understanding of what it really means we should divide it to smaller pieces – user stories. Every user story should match the following template: “As X I need/want Y to do/so that Z”. As a logged in user I want to update the details of my videos so that they be correct.
It is extremely helpful when a user story has at least X and Y defined since it clearly expresses the main role of the feature (As a logged in user) and by so the relevant business stakeholders of this feature.
Will we fail if we won’t name our user stories like that? Of course not.
Do all the user stories need X Y and Z defined? Definitely not. However doing so makes you truly understand the scope and value of the feature.
Epic: Allow users to find, play and comment on videos




Few things to note:

• The DoD adds meaningful information for the implementation of the feature.
• The use of user and logged in user for separating the action of an anonymous user and a logged in one.
• The priorities of the user stories determine what the most important feature to the user is and which one is the least.
• Every user story gives actual value to the user and brings us closer to the epic’s DoD.

Now we can split the top user story to its technical parts – the tasks.
User story: As a user I want to play videos from a list of videos




The complete backlog:

So now after we are familiar with all the product backlog items it is time to give them estimations.
But how do we estimate?
What estimation units should we use?
What are story points?
Do we have the same estimation units to all the backlog items?
 
All the answers and much more are in the next post.
 
Estimations in Agile development – Epics, User Stories and Tasks (you are here)
Estimations in Agile development – Estimating User Stories with Story Points (go here)
Estimations in Agile development – Sprint Planning Methods: Capacity vs. Velocity vs. Feature
Estimations in Agile development - Improving Estimations using Burndown, Burnup and Actual time metrics

Should we use MVC for modern web applications?

MVC is one of the most commonly used design patterns in web applications. It can be used both with server and client side rendering. Frameworks like ASP.NET MVC and Angular adopted the pattern and made the development extremely easy and straight-forward.

Despite its popularity, I claim that the MVC pattern is no longer the best solution for creating rich and modern web applications.

 

MVC – the good parts

Single Page Applications rule the web with different client side rendering frameworks like Angular, Backbone, React and many more. These frameworks made JavaScript development easier-and by doing so made the client “smarter” and the server “dumber” by mostly being responsible for communicating with the client and data persistence. Most of the applications’ logic moved to the client side.

In order to support this transition the MVC pattern has moved to the client by creating controllers that manipulate data (the model) that is presented in the views. This makes a lot of sense, as opposed to using just jQuery for some simple DOM manipulation and handling all the heavy lifting in the server.

So instead of rendering the view in the server for each request, now it’s extremely easy to render it in the client and give the users a faster and cleaner experience.

“Magic tricks” like two-way binding allow applications to respond quickly to different events and change the appearance of the app accordingly.

Let’s have a look at the Angular docs website. We can easily navigate through the different sections in the website while avoiding a trip to the server for rendering the next page.

That is a classic MVC case. It works great for the “simple” apps where most of the page content is static and the user’s changes don’t affect different parts of the page.

 

However, this is not what rich modern applications look like.

Let’s look at this example. What happens when we increase a product’s quantity? 

 

Four different parts of the page change (the header counter, the notification, the quantity of the product and the cart title).

 

Let’s try to implement it using Angular

Obviously I won’t build the entire app in a single view or use a single controller. That’s the worst practice, since it will break the SOLID principles of development by creating a giant controller that is responsible for EVERYTHING. This will become difficult to maintain over time.

I want my code to be highly reusable and simple to use, which I can achieve with components. Angular provides me with directives and, since Angular 1.5, it also provides components. I will create a controller, a directive and a template (view) for each of the following elements: the header, the notification and the quantity counter. In order to notify the other components that a product was added to cart, I can do 2 things:

1. Use $rootScope and raise an event on it while subscribing to it on the other components.
2. Use a shared service to pass the data between the components.

 

MVC doesn’t provide us with an out of the box solution for cross components communication. We need to extend it and create workarounds.

Here we saw just a single use case for cross components communication. For an entire application we’ll have many different events that will be managed using shared services or the $rootScope.

 

Does MVC help?

MVC forces us to separate the logic that is in the controller from the view that is just a template. It sounds like good practice, but if you think about it (and don’t kill me right away) maybe that’s actually not so good.

We are creating components, self-existing components that, like it or not, have their logic coupled to their view. You can’t really change the controller without affecting the view, and vice versa.

That’s alright! The components can be “smart”, they can have logic, handle their state and respond to different events and properties in a different way. So if that’s the case, why do we try to extract the logic and make the view dumb?

Why not create components that define their functions, handle state and create the view in a single class – a real reusable component. This component will use actions to trigger events that will be dispatched through the application and notify other components that something has happened, and allow them to respond if it’s necessary. This pattern is called Flux and it’s used widely with the promising new framework React.js.

Flux introduces three new features that create the necessary infrastructure:

1. Action – A simple class that defines the events that components may trigger.
2. Dispatcher – A class that dispatches the events from the Action to the different Stores.
3. Store – A store catches the events, processes them and then fires a completion event that components may subscribe to.

 

Let’s implement the previous example with React and Flux

Here’s a basic Flux file structure. You can find all the parts we discussed earlier here.

The + button will call an action, which will trigger “INCREASE” event.

 

The CartStore will respond to the event, calling to the server and actually modifying the product’s quantity.

 

Then the store will fire a “PRODUCT_QUANTITY_WAS_CHANGED” event to notify who ever listens.

Then each component that subscribed to the event will be notified and will act accordingly.

 

What’s the difference?

Nothing mind-blowing really. However, we don’t need to create a controller and separate it from the view and then subscribe and fire events in order to communicate. We build components that are responsible for themselves. They constantly pass events from and to each other, allowing us to easily change existing behavior, add new components and integrate them with the existing events.

The classic Model View Controller separation seems a little bit redundant, hence it must be completely changed for creating rich and modern web applications.

 

Agree? Disagree?

Share your thoughts.

 

* I want to thank Yonatan Mevorach for reviewing this post.

My Adventures in the Interviews Jungle

 

As you know I recently switched jobs and while finding a new one I’ve done quite a lot of interviews in different companies.

I really enjoyed the process! Some days I had 3 interviews in a row! My friends called me insane but hey, I can easily talk about software all day long!

While looking for my next job I took the way a company’s interview process as a major factor for my final decision.

In my opinion the interview process should reflect the values, the culture and the professional level of the company. A company that values my time, tries to make me feel like home and asks question that actually reflect my knowledge is most likely a better company than a one that does the opposite.

In this post I want to share some of the questions and tasks that I had in my interviews. Some of them were great. They actually allowed me to show what I know and the overall process made me feel wanted and special. On the other hand there were some that were a complete waste of time.

Let’s start.

Ridiculous, exhausting and a waste of time

Bizarre questions

“How many hair cut places are there in Tel Aviv? How many golf balls can fit into a bus?” These questions were famous due to Google’s interview process where candidates had to answer super hard and bizarre questions.

Few years ago even Google stopped asking these questions!

“They are a complete waste of time” - Laszlo Bock, Google's senior vice president of people operations. 2014.

I couldn’t agree more – these questions don’t test anything and furthermore don’t have anything to do with the candidate’s future work.

When my interviewer asked me these questions I asked if their company found it useful. He replied ‘yes, Google does it and so do we’.

That was a red sign for me – if you copy from someone at least stop when they do.

 

Endless trivia questions

By “trivia” I mean questions that don’t make the candidate think. Usually they start with what and not with why. Those questions check whether the candidate knows the answer or not. “What is HTTP? What is a transaction?” They don’t focus on the candidate understanding of why something is used or how is it used. Only if he knows the definition.

Honestly - when was the last time that you used a Mutex? Or had trouble with the GC? Either way it’s googlable. So it’s ok not to know all the answers.

I think that some trivia questions can be useful for three reasons:

1. To check if the candidate is serious about the job and that he took his time to prepare for the interview. Serious candidates usually prepare themselves and come ready for interviews.

2. To check that the candidate is not a complete noob/code monkey. It’s a bad sign if he cannot answer any question.

3. To check if the candidate knows how to say that he doesn’t know something. If he tries to lie and make up an answer in the interview then he will probably do it again in a real situation.

In one interview I had an hour and a half of trivia questions! Needless to say that it was one of the most exhausting interviews I’ve ever done.

In the end I asked the interviewer if they actually need all this knowledge to their day to day work. He told me no. They don’t even use multi threading but he questioned me for 40 minutes about mutexes, threadpool and thread synchronization.

 

Writing code for hours

In one company I had a coding test as the second interview phase. I think that it’s essential to check the way the candidate writes code but and this is a big but it shouldn’t take 6 hours@#$!

A small coding task should check if the candidate writes tests (perhaps TDD), uses SOLID principles and that his code is clear and well written. A simple calculator task can check all these. Writing a 6 hours long project is a waste of both the candidate’s time and the interviewer’s.

The worst part is that it’s in the company office (and not a home task) so the candidate will be stuck for 6 hours in a row writing code for some test in some company. Writing some code in the company office is good but only if it doesn’t takes the whole day.

 

Text exams

As I mentioned before, there shouldn’t be more than a few trivia questions in an interview. The only thing that is worse the asking 30+ trivia questions is having them in a written exam while the interviewer is not even present.

Those tests give the candidate the feeling that his time is not valuable enough for an interviewer to be present while he answers.

As a candidate I want to have the feeling that I’m wanted and that my time is valued. Leaving a candidate in a room alone with a text exam does exactly the opposite.

It can be even worse if the text exam is Scott Hanselman’s 25 things that every .NET developer ought to know and the interviewer tells that it is his private collection of questions.

 

The Good Parts

Now let’s go through the interviews that I really enjoyed, the technics and questions which allowed me to truly show my skills and made me feel wanted.

Home project, code review and pair programming

In one company I also got a coding project however it was a home project meaning that I could go home, work on it whenever I wanted and send them back the solution when I’m done.

This is so much better than working on it at the company during the interview. It allows me to put in as much effort as I want while doing it in a familiar and comfortable environment.

After I sent them the code I was invited to a code review. I think that this is the best possible interview since it checks everything! Both my coding skills, my ability to explain my choices and to see how I accept critics.

After the code review I was asked to change something in the code – it took just 10 minutes but the interviewer sat with me the whole time and was part of my design choices. It was more like a pair programming than a test. It allowed me to show how I think before I code, my TDD skills and it also allowed me to see how it feels to actually work with someone from that company. This was the best interview process!

 

Team Leader/Group leader who is in charge of the interviews process

As a candidate you usually talk to the HR in order to schedule your interviews, to get more info about the company and simply talk between the interviews. The HR are usually really nice girls (never met a HR guy) but it’s way more welcoming and respectful when your point of contact is a team or a group leader of that company.

It makes you feel important and that you are taken seriously since a manager is investing time from his busy schedule to walk you through the interview process in his company. A company that shows this kind of respect to a candidate must show even bigger respect to it’s employees and that is a company that I want to be part of.

 

CEO that talks to the candidates

I really valued the companies that their CEO invested ~30 minutes to get to know me and tried to make me feel like home even before I decided to sign with his or her company. When the CEOs shared their visions for their companies and told me their missions and values I felt an immediate connection. These talks were the last step of the interview process and companies who’s CEO actually called me or invited me to come and talk to him made me appreciate that company more than others and that is a major decision factor.

One CEO even called me from San Francisco just “to get to know me”. He is the CEO of ~100 people. If he could find the time then most of the high level managers in not huge corporate can.

 

Architectural and design questions

I was surprised to see that most of the companies didn’t ask me architectural questions. Only 2 companies wanted to know if I understood the architecture of the projects that I’ve worked on.

“Why do you have a load balancer? Why don’t you use micro services? Did you have a DRP? How does it work? What is the most fragile place of your architecture? What should you change? How? Why?”

If the trivia questions have usually the “What” prefix then the deep design questions will have the “Why” and “How” prefixes. This way the candidate must understand the pros and the cons of the architecture and more importantly to understand why the architecture is the way it is.

I think that these sort of questions show whether the candidate was just a code monkey or if he truly cared and understood his project.

 

White board role playing

Almost every company asks the candidates to approach the white board to solve a problem or design an algorithm. Remember that the solutions doesn’t matter! It’s how you thinks what’s important. This is why it’s important to think loudly and share your thoughts with the interviewers.

This is a great test however I think that it can be even better.

In one company after I solved the problem at the white board the interviewer stood up and told “now it’s my turn”. He asked another question (something about modeling and design) and then approached to the white board and started to sketch a solution.

Then he asked me if that works and if his solution was good. It wasn’t and I had to spot the problem and then explain him why his solution wasn’t good enough. It was great!

We switched roles and I felt like the interviewer. It was a simulation of a technical argument and he wanted to see if I can spot the design problem and most important part to see if I can hold on to my position and be able to convince him that he was wrong in a good and calm way. This is also one of the best interviews I had.

 

“How do you keep learning?”

There are plenty of developers out there. Only a small part of them are truly great developers. Many things distinguish them from the mediocre ones. One of them is what I call “Continuous Learning”.

The truly great developers always keep learning. They code, they read they write about it, they go to meetups and they are always up to date. Every company want these developers since they will always bring you progress.

If someone asks you to share this then they probably also care about learning and that place will probably have great developers who work there.

 

“Tell me about something that you are proud of?”

Enthusiasm and ownership are extremely important qualities. Every company wants their developers to be enthusiastic about their work, to have ownership for their features and to feel accountable for the application that they are building.

In order to be proud of something you must be involved in all aspects of the product development. You must feel that you own that something to the bones. If someone is truly proud of a feature or a product then he will talk enthusiastically while describing it.

I really liked when in one interview I was asked to tell about a feature that I was proud of. I could explain why did I think that this feature is important, it’s complexities and how did I actually developed it. It allowed me to show my understanding of that feature and my enthusiasm of software development. This is impossible to reproduce with only trivia questions.

 

That’s it.

This was a summary of most of my interviews. It was really interesting to see other companies and developers and to be tested for my skills. My personal advice is that when you go to an interview don’t be in the state of mind of a candidate that needs “to pass” the company’s tests. Go there and be the interviewer. Sure answer their questions, but don’t forget to ask yours. Remember that you are special and not every company deserves you. So be smart when choosing one. I think that the interview process can really help in deciding whether the company is worth going to. I hope that this post helped you know what to look for.

Good luck and feel free to share your experience!

 

* I want to thank Netanel Lev for review this post.