My unorthodox thoughts on working at the office versus remote work

The discussion that I keep seeing everywhere over and over again about office versus remote work is quite interesting. But not as much as it could be, because most people seem to have a similar opinion. Remote work is the latest fashion and is here to stay, but I have some unorthodox opinions that I thought would be nice to share too.

I started thinking about all this a few months back when I came across this video from Jason Fried, author of the book “Remote: Office Not Required” and Founder of 37signals:

* If you can’t see the embedded video you can try to watch it on the original website.

In the dramatisation, Matt Stillman is the CEO of a fictitious company and he discusses with Jason about remote work (and why he think it sucks). Obviously this video is a joke (it’s coming from Vooza anyway). I do have a sense of humor and let me agree beforehand that the video is kind of funny. 馃檪 But at the same time it called my attention because it reflects the real world in a way. The comments – although clearly exaggerated and supposed to be a joke – are an extrapolation of what fervous remote workers out there (like Jason, perhaps) think about office work.

For instance, Matt on the video says people can’t work from home because he hires “morons who can’t be trusted and need constant adult supervision”. Matt also says that “he would never want to work from home because he hates his family and only started a company to have somewhere to go every day and get the hell out of there”. Then it gets even more exaggerated when Matt says he evaluates employees badly if they get there 9:05am instead of 9am, or if they use Facebook at work. Again, the video is a joke as we know, but I’ve seen fervorous remote workers really using silly things like that as their real arguments.

I’m not here trying to convince anyone about working from an office. It’s just that when I saw the Vooza video it crossed my mind that I don’t think I ever saw an article about why it’s cool to work from company campuses. With my own experience in mind, here’s why I think working from the office is nice(r):


When you are in person with your team, the communication barrier is really low or inexistent, so it’s naturally better. A lot of the non-verbal communication (gestures, eye contact, body language, facial expressions, etc.) can get lost in remote teams, and those things are really key to make communication better and more effective.

Remote teams often find effective ways to communicate using Skype, Hangouts, Facetime and other technologies. I’ve done that too (to its full extent, including remote champagne celebration), and I can remember many instances where I couldn’t communicate because Internet went down, or connection was slow, or just to start a meeting we would need 15 minutes for people to get set up, or when kids were shouting and dogs were barking on the background and it was impossible to hear the other side, or when the call was just bad quality and it became unproductive… Those examples are not the rule, but when they happen during a key meeting, or, let’s say, your iteration planning, it really really hurts.

I’ve also seen remote teams (me included) using the Basecamps and Trellos of life. Basecamp for instance is a very nice tool, and It’s also built by Jason and 37signals, so I can totally make the connection that stimulating people to work from home directly contributes to his business and I totally understand why they do that so fervently. 馃檪 Jokes aside, those tools are great for improving remote communication and collaboration, but again you lose a lot of the face-to-face signals in that process. Many of the best ideas that I’ve had or seen people having happened in the middle of brainstorm discussions in a room with a bunch of people. Tools like Basecamp help indeed in several ways, but maybe your team is missing out in terms of discussions, brainstorms, collaboration, innovation, etc.

Bottom line is that communication is key for a successful software development team, and in my experience in-person conversations are the best ones.

White board discussions and radiators

Another thing that I really like to do (and is also related to communication) is using white boards and information radiators.

White board discussions make it much easier to get on the same page quickly with a bunch of people. I can think of numerous examples throughout my career where, at the end of the day, it took a bunch of smart people discussing, brainstorming and drawing on a board to solve a tough problem. Actually it just happened today (I’m not joking)! That to me is a big advantage of being altogether at the office. I bet there’s a tool that attempts to solve that problem, but I bet it’s not as productive as the good old “analog” board.

As an agile practitioner, I’m also adept of Kanban boards. This is by far my preferred tool to communicate priorities, track requirements and progress of a development team. There are again tools like Trello and many others that attempt to provide digital boards that can work well for remote teams, but one key principle of the Kanban boards is the principle of information radiation. When the information is retained (say, on Trello), you need to go there to find out what’s going on. When the information is everywhere (say, in the walls and whiteboards around you), you don’t need to go look for it, it gets radiated to you. When you walk into the room you already know what’s going on almost without having to look. You can have electronic information radiators too – and I use that a lot for Continuous Integration dashboards – but they work much better on a big TV in the middle of your work space like this.

Pair Programming

Pair programming is one of the nicest ways to get programming tasks done, especially the complicated ones that require a lot of attention. I’m not a fan of doing it (or enforcing) a 100% of the time, but it works really well and I like to do it more often than not. When you do it in person, you can have paper notepads and draw stuff to discuss, or have a to-do list to track things that you want to come back and do later, and many other things like that. You can do it remotely too, but doing it in person is at least one order of magnitude better. Maybe you can get used to it, but it was frustrating enough for me to not want to try anymore.

“Separation of concerns”

Separation of concerns is a common practice in software development: you separate your code into distinct sections, such that each section addresses a separate concern. I like to do that with my life too: work is work and home is home.

When I worked from home a few years ago I remember I would wake up and suddenly be working already, the hours would pass by, and by the time I noticed my daughter was already into bed and I didn’t even had the chance to say good night. At times it would be really challenging to get concentration going for a number of hours without usual “home” distraction like kids coming in and so on, and if you are a programmer you know that to do your job really well you need to get into flow mode sometimes. Lastly, if I was stressed with a tight deadline or anything like that, because I would “leave work” and “get home” in a heartbeat without even having some time to “decompress”, I would have lunch or dinner frustrated, with my family (and myself) not really enjoying my mood. Even a short commute like mine (10-15 minutes) helps you leave work at work and get prepared to have some quality time at home.

Hallway conversations

Hallway conversations are a great way of knowing what’s going on in different groups, share and learn with others, discuss our favourite tech topics with other geeks (like this week’s Apple Watch announcement), hear different opinions and so on. And when you work in a big company like Yahoo it’s especially good because you also get to meet a lot of new people this way (besides at trainings, in meetings and so on). If you like conversations and getting to know others, the office can be one of the best places to be.

Lunch with the team

My team and I have ridiculously fun conversations and a great time when we have lunch together. From thoughtful conversations to obscene and censored that I wouldn’t be courageous enough to mention here, every time we do that I feel we get to know more about each other and bond as a group, which directly impacts and improves the quality of our work as one unit. Remember the “whole is bigger than the sum of all parts” saying? This is one thing that definitely helps 1 + 1 be > 2.

“Decompression” activities

Have you ever been at a Nerf gun war? If not, dude, you are missing out! Not only that, but I also play table tennis on a regular basis (there was even a tournament a few weeks ago), basketball or beach volleyball sometimes during lunch, go to the gym (not so frequently these days), besides all sorts of really fun and relaxing stuff. Not to mention the soft serve ice cream machine, which is the 8th wonder of the world. I do all of that with my family over the weekend too, and we have a great time together. But that doesn’t mean I can’t have fun anywhere else, especially in the office where I spend a good amount of my time.


I don’t know, maybe I’m just very lucky and have always worked in amazing offices with the nicest people (probably true). But as I explained, there are also many communication and cultural aspects of working from an office that, in my opinion (and based on my experience), make the quality of the work and outputs better.

I’m far from being an “office work advocate” or anything like that, but I really like working at the office. Before you ask or think, I’m not saying this because I work at Yahoo (and by the way, the opinions here are my own and not Yahoo’s). If remote work works for you, that’s great! I’m very supportive. You should continue to do it. I’m not only very supportive of that but also office work and whatever else makes sense in your case and works for you.

Management Programming

Deploying to Production: When things go wrong, don’t make it worse! (a.k.a.: A story about Continuous Deployment)

Throughout my career working in software development projects I’ve seen many deployments to production go wrong or fail. It will happen to any software engineering team at some point, it’s a fact! Another (not so pleasant) fact is that people find many different ways to make the situation even worse. Bare with me, you will get my point in a minute.

Back in the 200Xs, the team I was working on deployed a bug to production that caused trouble to some users. Executives got upset and eventually put the blame on the deployment manager, saying that he allowed the release to happen without adequate quality assurance. This was actually the engineering manager’s (and team) responsibility, but since the other guy was blamed for the problem, he had the right to do something about it. And he did – he introduced a policy that would require teams to notify about deployments at least one week in advance so the release team could plan to do some black-box testing by themselves in advance and make sure things looked good.

Did you mean “lack of trust”?

This “solution” created a very bad “developer versus QA” dispute and lack-of-trust environment. Instead of collaborating, the development and QA/release teams were fighting against each other when they could be working together improving the product and quality. Not only that: the release process got substantially more complicated and time consuming, and in the end this only contributed for the company to be slower and more bureaucratic and didn’t fix the quality. Not to mention that when the next problem happened, the *development team* put the blame on the testing team too! They said: “It’s your fault, you didn’t test it right!”. How nonsense is that?

Another situation happened in a different company I worked for where a team released a new feature to production that almost completely prevented users to use an application. The solutions discussed involved a complicated release process that would require 2 weeks for a feature to be rolled out, locking the code repository so people couldn’t touch the code after some point and so on. And the result of all those actions are not different from the first situation: the team and company will get slower to release features, people become afraid of taking risks thus don’t innovate, the work becomes more bureaucratic, people become less productive, then become frustrated, and it goes on and on.

The pattern is simple: instead of fixing the actual problem, other kinds of problems are created in order to try to fix the original problem.

But how do you fix it effectively?

First, if you want effective immediate/short-term solutions for these problems, the initial step is to really understand what happened so you can fix the right thing. Was it that there are some parts of the system that are lacking test coverage? What is that the acceptance tests are not automated and the team didn’t do proper regression testing? Was it that the release process is manual and the release engineer was sleepy that day and ran the wrong script? Only when you know the root cause you will be able to do something effective about it.

Second and more important, if you don’t think about the entire system and think about a holistic solution, you will eventually run into the same problems over and over again in the future.

Bottom line: you need to fix the system, and not the problem.

People tend to go for short-term solutions that will apparently fix the problem but won’t (and also won’t prevent it from happening again). You shouldn’t be thinking about things like firing people or sending angry e-mails. The impact this would have in the system is that people won’t take risks anymore so they don’t get screwed up, thus they won’t innovate, thus your company will miss opportunities and your people could get frustrated and go somewhere else. And that’s pretty bad.

A real world example

One of the possible approaches that I learned and implemented over the last year is to implement Continuous Deployment, that consists in constantly deploying software to production in an automated fashion, several times a day, with little-to-none human intervention and with a high level of confidence.

And how does that fix this class of problem? When you implement such extreme deploying practices, you need to introduce amazing discipline, automation and quality, otherwise you will really screw things up. That said, the Continuous Deployment practice will naturally trigger several healthy behaviors that will end up fixing the software development system as collateral damage. Think about it.

Say that you want to have your product going to production immediately after a check-in on the version control system.

First thing you will need is to find a way to deploy code automatically to production. But you need to do it safely because you don’t want to disturb users using your application. One approach might be to take one of the servers out of your production cluster for a while, install a new version of the software, run some tests, and then repeat that operation until all servers are updated. But because you don’t want to do that manually (because it’s error prone and slow), you need to automate some smoke tests and the entire deployment process. As a result, deployment will be automated from tip to tail, including verifying if it went well.

If you want to go even more extreme and make your code go straight to production after a commit, you will want to make sure that not only the new just-added code is working but also that you didn’t break other things that were already working. But because you don’t want to test everything manually (because, again, it’s error prone and slow), you need to have a good amount of test coverage. In that case, Test-Driven Development, automated acceptance tests and Continuous Integration might be useful practices, as they will help you maintain a really high coverage and high-quality test suite. Also, you will probably want to do some code review because it’s always good to have another eye and brain do some verification, not to mention that this is a good practice to spread knowledge and understanding about the software. But because you don’t want to lose time and deliver customer value as soon as possible, you might want to go extreme and start doing some Pair Programming. And to prevent unfinished features from going live, you might want to use some feature flags too. As a result, now you have a very trustworthy process from code check-in to deployment in production. Not to mention a pretty damn fast team, because the system is so well engineered that they will be alerted if something goes wrong, so they get more confident and courageous to add features and make changes to the codebase faster.

And the cultural change doesn’t stop there

You also don’t want any big-bang deployments that change the entire application. You want to add features in small increments so that you can slowly and continuously change the system and see how it will behave. Even the big features you will want to split in smaller features that can be better digested by the team and deployed in smaller parts, either to see how users will behave or to see how the system/environment/code itself will behave. You will soon realize that you need to have shorter sprints, because you want to deploy to production right after things are ready. Why do you have to wait for 2 weeks to deploy if everything is ready? By the way, why do you need sprints anymore? Why not shifting to a sprint-less Agile approach? Sprint Reviews & Retrospectives no more – everything will happen all the time, just in time, after every story or task is completed. Deployments by the end of the sprint no more – deployments can happen at any time and all the time!

This is not a hypothetical story – it is almost entirely based on a true project that I recently worked on. By having the right mindset, creating the right culture and ultimately targeting at Continuous Deployment, we changed the entire development system & process and shifted everybody’s behaviors from managers to developers, QA and release engineers.

Control your outputs by controlling the system, and not the outputs.


Refactoring: Do it all the time!

Refactoring is a very well known technique that has been used for years in the software development field. Here are some popular definitions:

“Code refactoring is the process of changing a computer program’s source code without modifying its external functional behavior in order to improve some of the nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve the maintainability of the source code, as well as a more expressive internal architecture or object model to improve extensibility.”

Or, being more concise:

“A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.”
Martin Fowler

My concern with Refactoring is that most people don’t realize that they will have much more benefits if they do it all the time.

As the definition above explains, the purpose of Refactoring is to make code easier to change over time. It doesn’t make sense to keep adding features to your code for, say, 10 months and then stop-the-world for a couple of weeks to refactor it. If you’re doing that, you’re totally missing the point. In this hypothetical situation, not only (1) it would become more complex to make changes in the software over time – and you’d be in trouble for several months – but also (2) at some point of time the team would have to stop and re-engineer everything – because the software would become very difficult to change.

If a team waits for 10 months, or 2 months, or 2 weeks to refactor something, they are doing it wrong. Each time new features are added the code becomes more complex, and it’s necessary to review it as soon as possible to make the necessary improvements. If the team doesn’t do that often, they will become slower and slower each day, they will be less productive and deliver much less features (or value).

The “re-engineer” thing even worse. First, teams that stop to make huge refactorings are delivering nothing to their customers while doing that because they’re too busy fixing their own mess. It’s definitely bad to pay a software team to deliver nothing. Second (and more important), huge refactorings are often risky, because they change a great amount of code and software components, usually introducing bugs and unexpected behaviors.

To avoid all these bad things, you must do refactoring every day, all the time!

(1) Red, (2) Green, (3) RefactorEvery time you make a change, you must look for an opportunity to make an improvement. If you keep doing that, your code will always be clean, maintainable and easy to modify. Remember the TDD cycle: Red-Green-Refactor? Don’t miss the refactor part, do it all the time!

In my experience it takes no more than a few minutes to refactor if you are doing it in small chunks all the time, and more importantly, this will keep you from stopping to make huge and risky software re-writes.

Agile Business

The whole company “Agile”?

Last month while I was discussing with my friend Siraj we started to ask ourselves why the Agile “philosophy” doesn’t get popular in the whole company. What I mean is that nowadays it’s kind of easy to find the software/product development department of companies using Agile methodologies, but what else is missing or needed to the Human Resources, Marketing, Finance, Administration, Sales and every other departments join this movement?

When you start with Agile development, not only the software development process changes but many other things related to how your company works. For instance, it’s very difficult to think about an Agile team that will succeed with “command-and-control” management. The teams are self-managed, which implies a different style of management. Instead of bosses that keep asking for things done, we have servant leaders which provide all possible resources so that their teams can work and make decisions. The base of the pyramid begins to make decisions and not the top anymore, because they have the best work knowledge and therefore are the most suitable to do it. In some extreme cases in modern companies like Semco, the very employees are the ones who hire their managers.

That is, when we talk about agile methods, even though we are referring to the Agile software development methods, there are a lot of other concepts and philosophies that we are implicitly talking about (because they are very closely related).

I have an example to better explain where I want to go with this. I once worked for a company of reasonable size that, like many others of this size, had a traditional Human Resources department. One day I had a problem and needed urgent assistance from the HR staff. When I talked to them, two bad things happened. First, they treated me badly and like if they were doing a favor to me. Second, they said that my request would be met only in a few days because they had many important things to do first. What was happening was that my daughter was very sick, I had a problem with my health insurance and they were not willing to approve my daughter’s appointment with a doctor. A HR team with the “agile culture” would know in first place that since I am their main “user”, I deserve attention, respect and my problems are their problems. The emergencies of their users should be more important than any paperwork they have to do. And second, even though their backlog was abnormally large, a case with such severity should certainty jump the queue.

So when I say that other departments of companies could be “agile”, I am not suggesting that they work with Agile software development – which would make no sense – but that they use the same concepts of leadership, self-organizing teams working in a participatory environment, based on trust and cooperation, making a better effort to understand who are their “users” and what are their needs, create visions for their products and departments (that would help them make better decisions) and so on.

Getting this HR department above to speak up as an example, wouldn’t it be perfectly acceptable for them to do a personas exercise to discover what is the profile and the characteristics of their users? Wouldn’t it be great if they did chartering sessions, discussed their values, made retrospectives to discover how to improve their process and so on? Imagine how transparent and organized would be if the HR team had a big Kanban board in their room showing the activities, progress and their bottlenecks?

I think that this may not happen because much of the material and examples available on these subjects nowadays are formatted for people related to software development. Yes, there are books such as those of Ricardo Semler who are categorized in bookstores as “Business”, but I don’t see much business people really interested in these subjects. Why is that?

It’s time to finish with this “fork” between companies’ agile communities and the other departments. In Agile adoptions we frequently see after some time two totally different companies working within one. We must bring people from other areas and other hierarchical levels to the conferences and our world and show them these ideas. I will love the day that it will be possible to go to an Agile Conference and talk not only to software people but also HR managers, VPs of Marketing and other guys who are not in the development department; or else when we can find in user group meetings not only the “agilists” but also managers, human resources analysts, accountants and so on.

And now, where do we start?


Dev in Rio 2009, a great software development conference in Rio de Janeiro!

Even though it was conceived, planned and executed in a little bit more than 20 days, Dev in Rio 2009 was awesome, a huge success! We had around 400 people at the SulAmerica Conventions Center in my home town Rio de Janeiro talking about software development, programming at the Coding Dojo and having a lot of fun in a whole day of presentations that ended in the biggest #Horaextra ever. “Hora extra” (which means “Overtime”) is the name of our weekly meeting where the nerds hang out together to drink and have a nice chat about geek stuff.

Dev Rio in 2009 started at the scheduled time when me and my friend Henrique Bastos (the creators of the conference) opened the event with a quick presentation and thanking our sponsors, supporters, communities and friends who helped us a lot more than you can imagine.

Dev in Rio 2009 - Abertura
* Henrique Bastos and me at the Dev in Rio opening.

To begin the day, we started the two tracks of Dev in Rio 2009. At the main auditorium we had the scheduled lectures while in the foyer we had the Coding Dojo.

Coding Dojo is a programming arena that was organized by the Dojo Rio folks in partnership with Dojo@SP. The idea is to work on simple and novelty problems, using programming techniques like Test-Driven Development and SOLID principles. This was definitely the best surprise we had in the day – the Dojo went much better than we could ever imagine (except that the Java Dojo wasn’t much popular, I have to admit).

Dev in Rio 2009 - Coding Dojo
* Coding Dojo at Dev in Rio: 3 meters of code on the wall!

Dev in Rio 2009 - Coding Dojo
* People participating at Dev in Rio’s Coding Dojo.

The first talk of the day was given by Ryan Ozymek, that entered the stage with his famous penguin to talk about his experience with open source software and the Joomla! community. He detailed how a big software development community works and gave his entrepreneur vision about how to use open source software to leverage businesses.

After that, Guilherme Silveira and Nico Steppat talked about a very controversial theme: Is Java dead? They addressed the fact that there are many things beyond the language in the Java universe and that despite the language is “expiring” the JVM can still be very useful.

After lunch, Fabio Akita gave no respite for anyone who was sleepy and did an excellent presentation on the Ruby on Rails ecosystem, with excellent videos, screen casts and quite information beyond the code. He doesn’t know but he took away the breath of the simultaneous translation girls!

Continuing, the (almost carioca) Jacob Kaplan-Moss made his presentation on Django, that he calls “the web framework for perfectionists with deadlines”, developed in Python. He spoke about the concepts and values that guided the development of the project and showed a bit of code to give the audience an idea of how to use the basics of Django.

The last presentation of the day was given by Jeff Patton, that talked about product development with Agile methods. Using as a narrative the story of a project carried out in conjunction with Obie Fernandez, several common problems in software development (and their solutions) have been addressed.

In the end, our great friend Vinicius Manh茫es Teles led an interesting conversation between speakers, communities and the audience. We had the impression that if we didn’t control the time, the conversation would have taken hours and hours because there were a lot of interesting subjects and questions. The audience took a great deal and we had interesting topics like entrepreneurship and controversial as the stupid regulation law of the systems analyst profession proposed by the Brazilian government (in Portuguese only).

Dev in Rio 2009 - Discussion
* Discussion led by Vinicius Teles. And before anybody asks, no, that one on the picture is not Adam Savage from MythBusters, it’s Jeff Patton.

While all these things were happening, me, Henrique, Gustavo Guanabara and Flavia Freire (Arteccom‘s journalist) spent the day recording a huge podcast of the event, interviewing staff and filming the scenes. We have talked with the speakers, sponsors and attendees about all the subjects addressed on the talks! Watch the “making of” of some Podcasts with Ryan Ozimek, with Guilherme and Paulo Silveira and with Fabio Akita and Marcos Tapaj贸s.

Dev in Rio 2009 - Podcast recording
* Guanabara recording the Podcast with Fabio Akita and Marcos Tapaj贸s (and a neat detail: Guilherme Silveira and Paulo Silveira doing Pair Programming just behind them).

Since the event was realized on a monday, we ended the conference inviting everybody (with the “Estamos todos b锚bados” song from Matanza in the background and choreography by Sylvestre Mergulh茫o and Henrique Andrade) for an epic edition of #Horaextra (that means “Overtime”, our weekly social meeting) at Lapa 40潞. The entrance was free to everybody that had the Dev in Rio 2009 badge and that was how we realized the biggest and best #Horaextra ever:

* Watch more Dev in Rio 2009 videos.

I’m sure that this simple blog post cannot tell even 0,001% of what Dev in Rio 2009 was and how happy I am for being able to make it. I’d like to thank again the fundamental support from the folks of that was the main responsible for making it happen, our sponsors Caelum, Locaweb and D-Click and everybody else that have supported us some way: Associa莽茫o PythonBrasil, F谩brica Livre, Myfreecomm, OpenSourceMatters, Arteccom, DojoRio, Dojo@SP, #Horaextra, PythOnRio, RioJUG, RubyInside Brasil, and everybody that attended to Dev in Rio 2009. Without your support nothing would’ve been possible!

Dev in Rio 2009 - Everybody in the end
* Participants of Dev in Rio’s round table.

If you didn’t go to Dev in Rio, I have two things to tell you: (1) you did lose one of the best conferences in Rio ever but (2) we’re going to make the presentation videos available very soon to alleviate your pain. 馃檪

See you in 2010!


A story of failure with Scrum

Mental note: I promisse to post more often on this blog. 馃檪

While I don’t do it, see what happens when you use Scrum but you’re not really Agile:

Then see what happens when you don’t write unit tests and don’t do Test-Driven Development: