Monday, December 1, 2014

I'll refactor this later

1 comment:
Imagine this...

You're finishing your current ticket. The project manager keeps pinging you on IM, whether it's finished. This feature is important to a number of users. The business pressure is high. They want you to finish it ASAP.

"Could you deploy it before the lunch time?" - they beg.

You made some shortcuts in the code. It was just faster to put the code in the controller. You know how service objects are better, but this time it was just faster.

"I'll definitely be refactoring this later" - you think.

Just before the lunch, you push to master, run the deployment script. Everything seems to work. At the lunch, you're thinking how you're going to improve the code - extract the service object, add some more tests to cover the if branch that was added just at the last moment.

Back at the office. Everybody knows that you finished the previous ticket and the PM is happy. From the team perspective - you're now available for the next task.

"Could you help me debugging this problem?" - your colleague asks.

"We need the new reports in the admin panel" - the PM is back to you.

There's no way you can now fix the code shortcuts, you've made in the morning. You switched the context 3 times since then. There's just no time to do it. Other important things are waiting for you.

Did you just increase the technical debt? Is it your fault? You hate this kind of situations. You feel guilty.

Is there a way of avoiding such situations?

Can the code be debt-free?

In that story, you didn't manage to fix the code.
How it could have been done better?

Some people would say that you shouldn't deliver, before the code is great. The task is not finished, before the refactoring is finished.

"It's unprofessional" - they say.

There's some truth to that, but it's based on more assumptions.

"It's OK to have some technical debt, it's a pragmatic approach" - other people say. "Just document the problem somewhere" - they add.

Have you been in projects, where a special place for documenting the technical debt was created?

Some add it to the Pivotal/Redmine/wiki. Others try to keep a file in the repo - something like technical_debt.txt.

It can work, but it requires a huge discipline in the team. I used to be a big fan of this approach. After several approaches to it, now I think it's less realistic.

What are other options?

There's this "pragmatic" option to document the problem in the code comment. From what I see in the projects, I'm reviewing this may be the most popular option. I don't like it. I've looked at dozens of such comments, looked at the git repo history - the comments are almost always out of date. They're there and no one ever fixes the problem.

I really like another option. This practice alone isn't enough, but it's a good middle solution.

Document the hack in the git commit message.

Just write about the situation, why it was created like that, what were the time constraints. You may try to justify it a bit. You may explain how it can be fixed in the future.

Those messages are not part of the code, thus they don't make the code less readable. They are meta information, available to everyone, any time they want.

See a bad code? Just use your IDE to show the git logs for this place.

Bad code has other bad consequences. As developers, we like to point out the places, where code is wrong. Sometimes, a hack is implemented in 5 minutes (pragmatic), but then it takes 2 hours in the future for 2 people to discuss why it even got to the repository.

That's the real meaning of a debt. A 5-minute hack can turn into 2-hour discussion.

I've listed several approaches. I've tried them all. None of them is really good, right?

No hope then?

Well, there's another way of thinking. It's probably less spectacular and it requires better skills, but it can reduce most of the problems above.

First of all, there are hacks and hacks.

Some code should never be written in the first place. If you wrote a >100-lines method from scratch then it's a mess, not a code. Such code shouldn't go the repo. It doesn't matter if it's tested or not. There are some basic rules of coding that apply to our projects. It might be good for just spiking - writing some code to see if the concept can work. Afterwards it gets deleted.

Other cases are more on the technical debt side of things.

It's good to have such skills, that it doesn't make a time difference for you to write the code inside the action or in the service object. I just don't believe the time spent on typing those few characters/words more makes a difference. We're talking about seconds here, not even minutes.

More often, you're in situations, where you need to tweak some existing code to make the feature work. The original code wasn't yours - it doesn't even matter. What matters here is that this place requires a cleanup anyway. Let's say that you didn't have time to improve the existing code. There was no time for the Boy Scout rule. You've extended the existing action by some new 'if' statements. The whole path now works.

Now, this is the problematic situation. It's not your fault that the code was so bad at the beginning. You didn't improve it, though. You even made it worse. How much worse? It depends.

It's good to have a set of rules that all team agrees on.

Rails is so great, because it comes with conventions. As a team, you're not only choosing the web framework but also a convention framework. The problem is that at some point The Rails Way is not enough. This is the scary time when the team may not have enough guidelines. This is the time when it's not so clear anymore, where to put code and how to structure it.

That's why we coined the term The Next Way. It's a label to put some practices into. Service objects, form objects, adapters, repo objects. This is our way to solve the problem of missing conventions. It doesn't solve all of the problems, however it does help in limiting the length of the discussions.

The Next Way is just one possible set of conventions. We go with that but your team may choose anything else. What's important here is to have something that the team can agree on.

Thanks to The Next Way, we know what's the best format of a service object. Yes, there's lots of formats and discussing which one is best takes time.

So, The Next Way describes the goal. Your code is in point A and The Next Way code is Z. There's lots of steps in-between.

Being aware that improving code is a process helps a lot. Some would argue that being in point C is still bad. As long you as you all know that it's better than A - you can all agree that it's an improvement anyway.

Let's take an example here.

Imagine that your new feature requires displaying a new sentence in the view which shows the total value of the orders. The current view and action is very @ivar-heavy. There's no service object here, no repository objects as well. If you know The Next Way, then you know that removing @ivars is one of the steps we make to enable us for further steps.

In this interpretation, adding a new @ivar, like @total_order_value makes the code worse. It's not a big deal, but it's definitely not an improvement.

Now, what's good when you all have the commons set of techniques, like The Next Way is that everyone knows that it needs to be fixed. If you didn't have time to do it (like in the story we started with) in the first place - it doesn't really matter that much.


Because it's very easy to fix it. Once you know what is the goal, it's a matter of minutes to just turn the @ivar into an explicit rendering of a view following the "Explicitly Render Views with Locals" recipe.

Whoever next comes to this code and is more lucky with the business pressure can just fix it (with the help of the recipe if needed), commit, push, deploy. That's it. No lengthy discussions, no blaming, all clear.

I've seen many teams struggle when they entered the Beyond-The-Rails-Way phase. This phase is hard to avoid. When it happens, the team has problems with the consistency of the code. Sometimes the code looks like a collection of random blog posts. One technique here, another there. There are some good ideas, but there's no clear goal for all the code.

Once we've embraced The Next Way as a common set of techniques it was all easier. It is like The-Rails-Way-On-Steroids. It's more clear, where the code is. It's now clear when the code is in step C or closer to point Z.

What I'd like to encourage you to with this blogpost is to find your set of techniques in your team. This will help you and it will speed up your team work.

You can take what's in our book as a starting point and fork from there. The "Patterns" part of the book is all about The Next Way and its techniques. This is the description of the goal - the Z points. The "Recipes" chapter, on the other hand is all about the steps between the points.

Let me remind you that today (Monday) is the last day of the discounted price. The book is still $35 and you can still use the 20% off REFACTORING code when buying it. Later today, we will be releasing the 1.0 version and the base price goes up to $49.

Buy the book here

If you already bought the book, please consider starting the discussion in your team. Ask if it's clear what are the team conventions once The Rails Way is not enough.

Once you have the book, please don't just read it and put it away. The recipes need to be practiced regularly before they become a habit.

Start today - timebox 15 minutes, choose any action and try to apply the Recipe. I encourage you to start with the "Explicitly Render Views with Locals" one. It's a good start to get the feel of such changes.

There's a second episode of the Rails Refactoring Podcast - we're talking about the DNA of the Rails community and about The Rails Way. The whole episode is 35 minutes. We now also support RSS and iTunes, so subscribe to the podcast if you haven't done so yet :)

Friday, November 28, 2014

The Rails culture and The Rails Way


What is Rails for you?

Is it just a technology? Is it about the community?

Do you remember the first time you scaffolded a Rails application?

How did it feel?

Were you proud of achieving so much in so little time? Did you impress anyone by using Rails?

Rails is no longer the youngest technology around. Did it change anything?

Did you ever think how Rails ideas helped to shape the world? Did you notice how many startups choose Rails as the technology? It’s amazing that sometimes those people don’t fully know their business idea yet, but they know it will be implemented in Rails!

Rails changed the business world. For the better.

It was no longer so expensive to come up with a prototype or with an MVP. More ideas could be validated.

Some of the ideas were totally wrong. They didn’t have the market fit. Still, their authors lost less money than they would by choosing other (at that time) technology.

Many ideas (and their authors!) were validated positively. The MVP has proved to be interesting for the users. People wanted to pay for using it. Those ideas turned into businesses. Many of those still exist today.

As developers, we sometimes forget how much impact our work has on the world around us. All of the above wouldn’t have happened without us and Rails.

What about those less technical people? Did they have their chance in the Rails revolution?


It was late 2007 when I was contacted by a potential client. He said he was a fashion designer and he needed help with Rails deployment.


A fashion designer needing help with Rails deployment!

“What do you want to deploy?”, I asked, assuming he got some technical terminology wrong. “Oh, it’s a prototype of a web application which helps men choose good clothes for them.”

I looked at it and I was speechless. It was a fully working app, with a non-trivial algorithm implemented in Ruby.

It was actually ready for deployment. That’s all I was needed for here. This scared me. One year before, I decided to rely my programming career on Rails. Is this what I signed up for? Non-technical people being able to implement an application needing me just for the deployment?

I wanted to go back to my former Java world. To the world, where my job wasn’t threatened by fashion designers!

I realised that something big is happening.

I was lucky enough to be part of it. Rails enabled more people to be involved in creating web applications. I was very curious where it's all going to.

That was the time when new gems (they were called plugins at that time) started to pop up every week - acts_as_taggable, acts_as_anything, acts_as_hasselhoff (yes, there's such plugin: ).

The fashion projects ended very well. When the client understood that I'm faster than him in developing the features, he took care of marketing and other stuff. I wasn't just the deployment person anymore.

Creating new Rails projects in 2008 was like combining little pieces together.

At the beginning it was fun. However, the whole new wave of Rails developers started creating new versions of their gems every week. Each version had different dependencies. The authentication libraries kept changing every month at that time. At some point, it wasn't just connecting the pieces, but also hard work on untangling the dependencies to make it all work together.

The Rails Way was born

This concept was never clearly defined. It was a term to describe the Rails approach.

It's worth noting that at that time, everyone in Rails was coming from somewhere. I was from the Java world. Some people came from the PHP world. There were even some ex-Microsoft people.

At that time there were no developers who "were born with Rails".

When The Rails Way concept was appearing it was a way of distinguishing it from "the architecture astronauts Java way" or the "PHP spaghetti way". We needed to be unique and have something to unite us.

Most of our community DNA was very good, but there was also something negative. A big part of the Rails community was united with the anti-Java slogans. Everything Java-like was rejected. XML? No, thank you, we've got yaml. Patterns? No, thanks.

As a community, we entirely skipped the DDD movement, which took over the Java and .NET worlds.

"We don't need this"

"We've got ActiveRecord. We take the object from the database row and use it in all the three layers. Fat models or fat controllers? Whatever, let's just not create new layers."

This way of thinking became more popular.

The Rails Way was very successful

A new generation of developers started to appear. They were the ones who were born with Rails. Ruby was their first language. Rails was their first framework. The didn't bring the baggage of Java or PHP past life.

They joined the Rails community and embraced what was presented to them. That was The Rails Way.

What is The Rails Way?

It's hard to define it easily. I tried to do it recently and I found a few features that make it so uniq:
  • ActiveRecord objects everywhere, including the views
  • External gems used for most of the features
  • Non-trivial logic implemented with the combination of filters, callbacks, validations, state-machine - often in a non-easy-to-follow-way.
  • Magic - Convention over Configuration, DRY, metaprogramming
  • Only 3 layers - Models, Views, Controllers

When is The Rails Way good?

It's really good for developers who start their career. I keep teaching The Rails Way to the students - at the beginning. That's the most efficient way to get a result. It's the best way to stay motivated while learning more.

Within a project, The Rails Way is great at the beginning, when you're still not sure, where you go with the features and you need to experiment. In different project, the meaning of the beginning may be different. In some projects, I see the need to get out of the Rails Way as soon as the second month of development starts. In other projects it may be a year.

When is The Rails Way not enough?

When you start wondering - does that code belong to the model or to the controller - it's a sign that you may be looking for something more than the Rails Way.

When it's not clear how a feature works, because it's MAGIC - it's a sign the code controls you, not the other way round. You need something more to turn the magic into an explicit code.

When you start creating model classes which don't inherit from ActiveRecord::Base and you have problems explaining to the team, why you needed that.

When you try to test, but it either takes ages, because you need full integration tests, or you die by over-mocking.

When you try to switch to a hosted CI, but they are unable to run your test suite.

When you can only migrate data at nights, because the migrations lock the tables.

Learning from mistakes

I've had the "luck" to review hundreds of Rails projects over the last 10 years. The same patterns were visible over and over again. An app was in quick development for the first months and then it started stagnating to the point where no one was happy with the speed.

I've started collecting those patterns. I grouped them into code smells, anti-patterns, magic tricks.

Alternative architectures

Meanwhile, over the years, I was studying many non-Rails-Way architectures like DCI, DDD, CQRS, Hexagonal.

Then I started to draw lines between those two.

  • How can I get from the Rails code smells into DDD?
  • Does DCI make sense in Rails apps?
  • Is there place for the Hexagonal adapters?
  • What are the aggregates in a Rails app?

Ruby and Rails are very unique and specific. Some things fit well into it, while others seem foreign to the way we write code.

The Next Way techniques

  • service objects
  • adapters
  • repository objects
  • form objects
  • domain objects
  • events
  • presenters

From A to Z

I picked some of the building blocks of the architectures and tried to apply them in the Rails projects. The ones that didn't fit, I rejected. At the end, I only kept the ones which looked helpful for the typical problems.

This was just the beginning. Even if you know the starting problem (point A) and you know the end result (point Z), there's many steps in between that need to be made very carefully.

Safety of changes

I assumed the code transformations will be done on production applications. No place for any risk here. Some of the changes may even be applied to untested code.

Your application needs to be safe, even when you apply the changes. Your boss and your clients will never allow introducing any bug "because I was improving the architecture". It's just not acceptable.

Working on the recipes

It took me over a year to put together the refactoring recipes. Your code contains lots of small issues which make it harder to introduce a better design.

You won't introduce service objects if your controllers are filters-heavy. The dependencies will break your code.

You won't introduce service objects, if your views rely on @ivars magic. You need to be explicit with what you're passing to the views.

You won't make the build faster if it the tests still hit the database. You won't get rid of the real database as long as your ActiveRecord classes contain any logic. You need to introduce repository objects.

You won't introduce service objects easily, if your controller action can do different things, depending on the params (params[:action] anyone?). You need to use the routing constraints.

You won't find any shortcut, unless you know the SimpleDelegator trick which helps you move a lot of code into a temporary service object at once.

Those are some of the things I was working on. Those recipes are tested in big Rails projects by many different teams.

Those recipes work.
They will make your architecture improvement easier.

The book

This all led to me to writing the "Fearless Refactoring: Rails Controllers" book.

The core of the book are recipes. However, the recipes alone may leave you with just the mechanics, so we've added many chapters which explain the techniques in details.

We've also added the "Big examples" chapters. They take you through some (ugly) code and apply the recipes, one by one.

Thanks to all of you who bought the book when it was still beta since February I'm very confident about its quality. You sent me a great feedback. You sent me the before/after pieces of code. This book wouldn't happen without the people who trusted us so early. Thank you!

1.0 release

Some of you prefer to read books only when they are completed. Now is the best time to get it.

On Monday, December 1st, the book goes 1.0, yay! During the next days we still keep the discounted price: $35. On Monday, the price goes up to its final price ($49). On Monday, you'll receive the 1.0 book update, no matter when you bought it.

You can get the book at Use the REFACTORING code and you will get it 20% off!

(we also have the 1-day 25% discount for our "Developers Oriented Project Management" book with the BLACKFRIDAY2014 code - get it here: - many people switched to remote work after reading this book!)

Sunday, September 21, 2014

Terry Pratchett, the Long Earth and IT projects

No comments:
I’ve just finished reading the “The Long Earth” novel by Terry Pratchett and Steven Baxter. While I expected the book to be more Pratchett’ish in the sense of humour (it’s not) I found it a very inspiring read anyway.

Parallel worlds

“Long Earth” is based on the idea of parallel worlds. While reading it, I couldn’t resist the temptation of imagining what would happen if we had the same idea applied to IT projects.

Remember the last time you started a project? I’m sure you’ve had some ideas on which architecture to choose or more likely, which language/framework to base it on.

Should we go with Rails? Isn’t node.js the better thing nowadays? Is it a good idea to go with CQRS here? Scala will save us? This time it will be better?

Now, imagine that all the decisions were made and all the alternative realities are happening.

Let’s say, that in the Primary World you went with Rails, Angular, without CQRS.

3 months in, you have the typical Rails problems, the models are overloaded with responsibilities, the controllers are not really that thin. The build now takes 5 minutes while most of the frontend code is untested. The team members start complaining - “We wouldn’t have such problems with Node.js”, “Can you see it now - we should have gone with CQRS in the first place”, “Scala, we need Scala, because of reasons (monads)”.

Given the idea of parallel worlds (or rather parallel IT projects), you could jump into the world where Scala was chosen, just to notice, that the project is even in a worse shape, because some people didn’t get the idea of non-mutating state and it’s all not pure enough, while the frontend is not done at all, because all the time was spent discussing why Scala is actually worse than Haskell.

Then you jump into the node.js alternative world. A quick look at the codebase - yes, callbacks everywhere. How did it go with code reuse on server/frontend? Oh yes, they don’t really share that much. Also, part of the codebase is in JS, while the other parts are in CoffeeScript, because you hired those new JavaScript developers, who hate Coffee, while the Rubyists in the team can’t parse JS at all.

Wouldn’t that be great?

It’s all science-fiction obviously. I wonder, though, how much would it change our decision making process, if we knew that we could always look at how it goes in the alternative worlds.

Would it make our decisions better?

Would we learn that all projects have problems at some point, despite the technologies and architecture choices?

Would we learn that no matter what we do, we may end up with another legacy codebase?

Now, back to reality. We have only one, the Primary World. We can’t jump into other worlds. What tools do we have to measure our decisions? Is it actually worth to measure at such a high level?

Maybe it’s better to just learn how to get out of any mess that we (and others) create?

Wednesday, July 2, 2014

The secret to change your team habits

No comments:
Over the last few weeks, we've been sending several lessons to our Arkency Newsletter  (not there yet?) on how to become more Async with your programming team. They included techniques like:

Async, textual, standups
Async knowledge sharing and gathering documentation before synchronous online meetings
Using and building tools which can greatly support you with your async and/or remote environment
Splitting bigger stories into smaller ones on the fly
And more...

By applying those lessons, you can make your team more effective. It doesn't matter if you do Rails, Python or Java. The team techniques and problems remain the same.

I'm sure, you've noticed that it's not as easy to switch the team habits to the new ones.

Why do the people forget to work on small stories only?
Why it's so hard to introduce async standups instead of the sync, voice-based ones, that everyone loves?
Why are people not reviewing each other code changes?

The thing is, it's hard to eliminate habits (ask any smoker!).

There are two rules for introducing new habits:
  1. Know what's your goal, what are the new habits to introduce. Luckily, you know the techniques we suggested in our email course and in our book.
  2. It's easier to change existing habits than to eliminate them

The second point is crucial (and that's the secret!):

Habits are based on hooks (think Aspect Oriented Programming, but in real life).

What are the current habits in your team? Is it that everyone prepares at 9.50am, because at 10am the standup starts? Don't try to eliminate it (yet), just turn it into something different. Do the text-based standup instead, even if it's at the same time with everybody. Just share your statuses in the communication tools or in the Google Doc or Hackpad. That's a smaller step and probably more likely to be adopted. Heck, you can even do it, while all are on Skype, if you prefer even smaller steps.

There's a cool concept of Tiny Habits, that can help your team change more easily. This concept is directed towards single people and their habits, but the mechanisms stay the same for the team - try it and apply it for your team (it's free!):

A good experiment is to identify your team "hooks". Some example ones may include:
  • a new commit pushed to the repo
  • new build failure
  • standup time
  • weekly meeting time
  • start of the day of work
  • end of the day of work
  • lunch time
  • new deployment
Once you identify your hooks, try to replace the actions that happen before/after the hook happens. Make it as simple as possible!

Let's say, that one of your goals is to increase the knowledge transfer in your team and you decided that the 'foreman' technique is the way to go. The simplest form of 'foreman' is to review someone's else code. You can gradually introduce it as a technique in your team, that whenever anyone finishes a ticker ("after finish ticket" - hook), they look at some of the recent commits (action!) in the repo and comment on them (even if it's a simple "+1"). At the beginning, you can make it just 10 minutes. It's enough to at least look at some code.

Hook: You finished a ticket
Action: Review someone's else code for 10 minutes

You can't do much in 10 minutes, but if you know the Kronos/Chairos time management technique, that we were promoting, you know how to use the time best.

Good luck!

If you feel, like there's still more you can learn about the new async team techniques, just grab our recent book - it's designed to safely refactor your team towards being more effective!

Tuesday, June 10, 2014

Custom exceptions or domain events?

The topic of custom exceptions is surprisingly controversial. Some argue that exceptions shouldn't be used for anything related to "business", while others (me included) say that exceptions like InsufficientFunds are fine - I even wrote a whole chapter about using custom exceptions to simplify controllers in my Rails Refactoring book.

I've read an interesting blog post today about custom exceptions (here - unfortunately it's in Polish), where the author advocates for using "business exceptions".

The example comes from a dialling application, so there are the following exceptions:

  • CallAlreadyInProgressException, 
  • IncorrectNumberException, 
  • NumberAlreadyDialedException

When I first looked at the code, I nodded in agreement. Given such domain, those exceptions make total sense to me. I'd implement it the same way.

When I linked to this post in our team chat, Mirek (who has more knowledge about DDD and CQRS than I do) said that it'd be better to implement with domain events. This surprised me a bit, as when the topic of custom exceptions is brought up, domain events are rarely shown as an alternative.

What's the difference between custom exceptions and domain events?

Look at this code:

Domain events decouple the call to the method from returning the result. This is at the core of the CQRS approach - one of the most inspiring architectures I've ever read about. In short - any system operation is either a Command (a change to the system) or a Query (a read from the system). This rule drives the whole architecture.

In the code, it means that when you call, you're not directly interested in the result, even to the point, that the method can fail (raise an exception). You made a command and that's it.

Now, obviously, you do need to know about the failure. That's why you publish an event, using whatever mechanism under the hood. It can be a simple singleton EventBus class, which just keeps a map of objects interested in certain events and notifies them if any such event happens. In our case, we could have a UINotifier class listening to the CallAlreadyInProgress event and sending a special UI message to the user of the system (the technical details are not important here - it can be via polling or Web Sockets).

There is another difference - with events we need to "publish" the fact that all went fine. What was implicit with exceptions (no exception is raised - success), here needs to be explicit. We publish the "ConnectionEstablished" event.

This creates a nice simplification of the whole code around it. It may make it a bit more indirect, but it's actually very simple. All of the pieces of code involved do just one thing.

Wednesday, May 28, 2014

Remote team - mobile tools

When working remotely and/or asynchronously you may be often in situations where a mobile access to the team/project data is very useful. See my previous blog post on desktop tools for remote teams.

Here is a list of tools I often use in the context of the Arkency team. I use all of them from my iPhone 5s. I think most of them have their Android versions.

  • Team/project
    • Slack
      • our IM tool of choice, good UX, easy to use, even with a 20+ team
      • the nice thing is that it caches all the history of our channels, so I can sync with them whenever I want
    • Hackpad
      • accessing offline and creating hackpads offline is the killer feature
    • Trello
    • iOctocat
      • This app pushes me a notification whenever any new commit appears in any of my github repos. I can easily review the diff, comment on the changes or just browse through the code - highly recommended!
      • basic version is free. it's worth upgrading to receive notifications ($12.99)
    • Mumble
      • the voice communication tool of our choice, push to talk, multiple rooms
  • Social
    • Twitter
    • Facebook
    • AlienBlue
      • a Reddit client - useful if you often post your blog posts to Reddits
      • free, but worth upgrading for $1.99
  • Getting Things Done
    • MindNode
      • $9.99
      • it's the mind mapping tool, that I was looking for a long time
      • it has a Mac version (paid separately) and integrates/syncs via iCloud
    • Evernote
      • Quick to find important information, even from a mobile.
  • Geo
    • Foursquare
      • Even though, we are a remote team, many of us live in the Wroclaw area. When people are in the habit of checking in, you can easily see if anyone is close to you right now. I'm a strong believer of async/remote work but when there's a chance to meet face to face, that's always a good idea!

This blogpost is a work-in-progress chapter from the "Developer Oriented Project Management" book. The book is just weeks before the final release. Grab it now, before the price goes up!

Monday, May 26, 2014

Async standups

No comments:
When you work remotely, you want to have some kind of a standup meeting regularly. In our team, after experimenting with many different approaches, we settled with text-based, asynchronous standups every day. Additionally, every project has a weekly 'sync' meeting.

Whatever tool we currently use for remote communication (irc in the past, now Slack), we create a channel that is dedicated to #standup. We don't have a specific time to post there, usually we do it, when we begin our work session - so, in the spirit of async - different people at different times.

I consider #standup to be a very good opportunity to communicate cross-project, to educate, to learn, to help. Short standup messages are not bad, but they miss this opportunity.

When writing the standup message, think more about the others, than about yourself - what can they get from it by reading your status?


Yesterday I finished the "fix the price calculator" feature, which was mostly about removing the Coffee code and rely on the value retrieved from the backend, via ajax. The nice thing was that the backend code was already covered with tests, while the Coffee one wasn't. After that I helped Jack with the "allow logging in with email" feature (we need it now because we have a batch import of users from system X soon). After that I did a small ticket, where I block buying licences for special periods of time. This was nicely TDD'ed, thanks to the concept of aggregate, introduced by Robert recently - all the tests pass < 1s. Here is a commit worth looking at: .
Today I'm going to start with foreman'ing the recent commits and after that I want to work the XYZ system to allow a better editing of entries. I'm not sure how to start it, so all help is welcome.

What's good?

  • many details, 
  • letting other people jump in and help me,
  • some opinions about the code that I saw, 
  • some details about practices I applied (TDD, foreman'ing) 
  • reminds about some business information - import of users from the X system, happening soon 
  • links to the commit (potential education) 


1. yesterday
2. today
3. good thing
4. bad things
5. challenges
6. call for help
7. reminder about good practices (tdd, foreman, help colleagues) 
8. code examples (link)
9. business-related info

(this blog post is a work-in-progress chapter in the Developer-oriented Project Management book.)