One year ago I joined Plataformatec and today, I’m going to tell you some practices that I have learned while working here during all this year. I hope you’ll find something helpful to improve your team or your company.
Sustainable work hours
Some companies expect their employees to work overtime when a project gets close to the deadline and it’s not finished yet. When I came to Plataformatec, I discovered that the default here is to work in a sustainable way (40 hours/week). There have been a few exceptions, but we are not encouraged to do so, and the extra hours can be compensated as well.
Software development tools and practices
At Plataformatec we choose to start with a small set of basic tools and practices, adapting as we learn about the project and the customer.
One of the practices that I liked the most and had no previous experience with is the retrospective meetings. If you never heard about it, it’s simple! It’s a meeting that we do at the end of an iteration, reviewing everything that happened: not only the good things, but also the ones that we need to make better, so that we can plan actions to continually improve. For me, it is a very pleasant meeting because it’s an opportunity to recognize the good work someone has done or to search for a solution to a recurring problem. One interesting fact is that we also use retrospective meetings internally, for the whole company itself.
We don’t cut corners
We really care about our customer’s products and the code quality. We don’t like adding ineffective, incomprehensible or quick-and-dirty code (also known in Brazil as “gambiarra”), because we know that it may cause problems in the future.
We know that it’s not that easy to avoid bad code and beginners mistakes, but there is no definitive solution for this kind of problem. Here at Plataformatec we use two tools to achieve a greater level of code quality: our guidelines and a simple process called code review via pull request. If you’re going to adopt just one of these practices, choose Code Review.
Every single line of code matters, that’s why it’s better not to put all that responsibility on just one person’s shoulders. The code review process can help with that. When doing code reviews, everyone in the team is accountable for the code that is being shipped, not just the developer that created the pull request.
Before working here, I thought pull requests were only an open source practice, that it didn’t have place in commercial projects. It was really mind blowing to see how it works on a daily basis. We reduce errors, ask for help to an experienced programmer, learn about features of frameworks and languages, discuss algorithms… it is an awesome communication tool, and the best part is, all that communication happens in the context of the source code.
It’s simple: we do software development, we work hard to improve the way we do it and to become one of the best references on it. The whole company works as a team, and everyone shares the same goal. It means that the salespeople close the deals with terms that developers and managers can work in a healthy and challenging environment, and, most importantly, the customers know what to expect from us.
It was a surprise to me when I came here and saw that all of my new coworkers love the programming community and that most of open source work is done during their free time. We are frequently encouraged to contribute to open source, attend to local and international events, write blog posts, present talks and discuss software development subjects on our Hacking Evening every Tuesday. Best of all, you don’t need to do it alone, there is always someone to lend you a hand. Knowing these people and working with them motivates me and help me love more what I do every day.
That’s all I had to say for now. Working at Plataformatec has taught me a lot of good lessons and I know I still have a lot of things to learn. I selected the practices that I liked the most and wanted to share.
Do you have any practice that you appreciate? Tell us about in the comments below!
Last month our team went to Agile Trends, an event in São Paulo where discussions revolved mainly around Agility in software projects.
Starting the event activities, Niels Pflaeging presented a keynote where he defends Agile alone is not sufficient to taking organizations to the Knowledge Era, and that deeper transformations are necessary for doing that. He started it with an overview of the History of Management, why bigger companies are structured the way we know them and what he believes needs to change so they can adapt to the new reality and remain competitive.
After the keynote, the so-called “Trend talks” started. Each Trend Talk session was composed of two 18min talks revolving the same theme, followed by a 20min discussion round. In the Trend talks, most of what was presented and discussed was related to the challenges companies face when adopting agile.
During such presentations, most of the success cases presented how companies have adopted the Agile principles but adapted the practices to their own realities, be it a startup or a bigger corporation. Which is similar to what we’ve been doing in our own projects: whenever we start a new engagement we use our custom methodology as a Starting Point and, as we get to know more about our clients, we adapt it to better suit their realities.
Other presentations also showcased some of the Change Management challenges that companies have to face in order to make this work. These topics are similar to our own challenges when engaging client projects, and it was interesting hearing the struggles from other professionals so we can make sure to always keep our toolbox up to date.
The event also contemplated some workshops, and we joined one that had Kanban as its theme. In this workshop, we honed our skills while running an imaginary pizza place (too bad the pizzas weren’t real) and as we progressed in the game, we could also buy adjustments to our workflow in an “upgrade store” using the cash we made. The point was to get us thinking about how our decisions affected the business’ performance and profitability. Besides that, we also joined a workshop about Learning 3.0, where the participants were divided in small groups and each group had a real problem to work on. We had to understand, share experiences related to the problem and discuss ideas about how to solve it. In this workshop we had the opportunity to work with people from other companies with different backgrounds, which contributed to bringing different perspectives to the discussions.
Finally, we also attended some interesting Keynotes addressing themes that were not directly related to Agile, such as Internet Privacy and the Internet of Things. Even though not directly related to project management methodologies, they were nice in the sense they help us keep our minds open to other trends related to the tech landscape.
Being part of the event was a great opportunity to see how events related to Agile have gained increased traction during the past couple of years. It was also nice meeting old friends there, as well as meet new people.
Have you also been to Agile Trends? Did any of the talks catch your attention in special? Please let us know it in the comments.
Charlie Somerville recently tweeted he wished there was a good guide about maintaining open source software:
I wish there was a good guide on maintaining OSS projects. I'm a maintainer of a reasonably popular project and I have NFI what I'm doing.
— Charlie Somerville (@charliesome) April 26, 2014
In between consultancy jobs and building projects for our clients, our team is directly involved in many Open Source Projects. So after exchanging some messages, I realized it would be useful to document some of the common practices we do at Plataformatec for maintaining Open Source Software.
Although this post is not a complete guide, it does share our experience of maintaining and working on the issues tracker of many projects like Rails, Simple Form, Devise, and lately Elixir.
One of the most important things when it comes to OSS is to avoid burnout. This is extremely important for small projects, which mostly depend on one or two contributors. If someone burns out in large projects, there is always someone else to take on the issues tracker and maintenance work until you gather your energy back.
For small projects though, if you need to step away, it likely means the project will go unmaintained for a while, which will just make the situation worse as issues will continue to arrive.
So a lot of what we will discuss here is meant to avoid burnout. Here are two examples:
Avoid issues from piling on – it is likely that, if the issues tracker has 30 open issues, you will feel less and less compelled to work on them;
Learn how to say “no” – merging code or features you are not a 100% comfortable with may makes thing worse. Every time there is a bug on that particular feature, you may feel less compelled to work on it or even not be willing to improve/refactor the code in the future, etc;
Of course different developers have different reasons to burnout, so whenever you find yourself lacking the energy to work on a project, try to understand why the energy isn’t there and find ways to avoid the problem from repeating in the future.
If you are hosting your project on GitHub, GitHub allows you to place a
Contributing.md file with instructions on how to contribute to the project. For example, here are the files for Devise and Elixir projects.
Remember the community wants the same as you: the best for your Open Source project. So having detailed instructions on how to collaborate and contribute to the project helps both you and the community. You will have more detailed bug reports, better patches/pull requests, and other developers will find it easier to give back.
However keep in mind that there will still be incomplete or wrong reports from developers that didn’t read the
Contributing.md file. That leads us to the next tip.
ABC (Always Be Closing)
If you have ever been to a sales workshop or read about how to improve your sales skills, it is very likely you have seen Alec Baldwin’s speech from Glengarry Glen Ross:
Although we are not doing any sales here, I strongly apply the concept of “Always Be Closing” to the issues tracker. I am always, actively, closing issues. Here are the main reasons I close open issues:
The user has not read the
Contributing.mdand have posted a bug report without the relevant information like OS, software versions, stacktraces, etc;
Users are asking questions on the issues tracker when a project has a specific channel for those, like a mailing list or a tag on Stack Overflow;
The proposed feature is too complex to not be worth the time that it requires to be implemented. Or you don’t see the possibility for the feature to be implemented in a medium-term plan;
Usually the first thing I do in the morning is to give a quick pass at my inbox looking specifically at open issues. Issues that are invalid or that cannot be acted on are closed with the proper message. In case the user provides the missing information after a bad bug report is closed, the issue will be reopened in the next morning. This activity only takes a couple minutes of your morning, which you can do while you sip your hot coffee.
Soon after I adopted this workflow, Vasiliy Ermolovich noticed most of the time I was closing issues with similar reasons, and he has created the extremely useful José vs OSS project which integrates with Firefox and Chrome to help me close issues more quickly. This project has probably saved me days of work!
Ask for contributions
The community is there to help you! There are many ways you can reduce your workload by interacting with the community:
Depending on the project, asking a sample application to reproduce the issue is extremely helpful. A lot of bug reports are closed after the reporter tries to reproduce the issue and, in the process, they find out the bug was caused by something specific to their application. It saves you precious hours from trying to reproduce a bug that you would never find!
If a user reports a bug, ask the user if he/she feels comfortable to send a pull request with a fix. If you have an idea of where the bug is, send the user links to the relevant part of code, and make it clear you are available in case there are any questions;
For Elixir, we are experimenting with tagging issues with their “perceived difficulty”, so users who want to contribute to the language can help you solve existing issues. I often list small/medium features we plan to tackle in there and often they are implemented by the community and sent as pull requests;
Find out what works for you and the community
The important thing is to find out what works for you, the other maintainers and the community. For example, while working on Elixir, I was used to close features requests that I could see that would not be part of the language in the next 6 months, even though they were features I liked too! This eventually led to some questions from the community about the approach taken in our issues tracker.
The truth is: if the feature is really useful, you will hear about it many more times! I explained the approach to the community and showed how not having such entries in the issues tracker helps us keep focus on actual bug reports and actionable tasks. Which led everyone to agree with this direction.
Try things and listen to the feedback and hopefully you will find a workflow that works nicely for everyone involved!
Finally, be nice and be polite! Let your contributors know that you appreciate their work as much as they appreciate yours!
What about you? Do you have any tips to share regarding OSS projects maintenance?
This year’s RailsConf was held in Chicago, from April 22 to 25, and Plataformatec was there, as in previous years, and this time it was represented by George Guimarães, Lucas Mazza, Rafael França, and myself included. Even though I’ve attended the last 5 RubyConf / Rails Summit here in Brazil, this was my first time at RailsConf in the US, and I have only one word to TL;DR it: awesome.
Chicago is a welcoming city, there are lots of nice tourist attractions to visit, and the conference was a great opportunity to meet new people, share ideas, collaborate, and learn new things from the well selected list of talks. But all of this is quite hard to explain in words, so I’ll go with the a picture is worth a thousand words motto and show you a series of pictures, hopefully they will show you better what I mean.
The highlight of the first day was DHH’s keynote about clarity, patterns and TDD, which sparked many conversations/discussions during the day. Farrah Bostic also gave a nice keynote at the end of the day, entitled What Happens to Everyone, When Everyone Learns to Code, which added even more to the topic DHH had covered.
In the second day I was a bit nervous, since I was going to give my very first talk in English, Tricks that Rails didn’t tell you about. I received awesome feedback from a lot of people after the talk and in the following days of the event, thank you everyone for that <3. You can check the embedded slides at the end of this post.
By afternoon we participated in the Community Office Hours sponsored by Heroku, where we gathered a lot of Rails Contributors to answer questions and help the community with any Rails issue they could be having. It was an opportunity to talk to different people and understand how they use the framework and the real problems they have, but it was not a very busy time for everyone, so some contributors had time to sit together and hack some stuff. What came out of that is a script to label stale issues on the Rails repository, marking them to be closed later in case no feedback is given in a timely fashion. Great stuff.
On Wednesday night we went to the Basecamp Open House event, and we took the opportunity to take a picture of most of the Rails Contributors present at RailsConf.
But we missed some folks on this picture, so we decided to take another. However, DHH was not present anymore, thankfully we had someone skilled enough to draw his double:
The third day was very important for us, but specially for my friend and coworker Rafael França: he got a Ruby Hero award <3 <3 <3.
As most of you probably know, Rafael has been doing an amazing work with Rails and all the surrounding environment, working on all fronts, solving issues, releasing gems, and being super present on discussions everywhere you can think of. Besides that, he dedicates some time to maintain our Open Source projects, for example lately he did some work to add Bootstrap 3 support to Simple Form (check the latest 3.1.0.rc1 version :D).
You deserve it, congratulations!
On Thursday afternoon we had the second turn of the Community Office Hours, this time it was busier and we were able to help many developers having issues. I hope we can do something like that during the next RubyConf Brazil. At night we went to Code Climate’s after party and had some beers. Rafael returned to Brazil on this day, heading to Recife for the Abril Pro Ruby conference where he was speaking (expect another blog post on this soon).
On the last day the closing keynote was a super awesome talk by @tenderlove, where he showed us that there’s a real need for science on our work, and then he merged AdequateRecord to Rails master while on stage! Well, not really on stage, but it’s merged :D. We also handed on our last Devise, Simple Form, Elixir, and Hacking Beautiful Code stickers. If you got one, please tweet a picture to @plataformatec, we’ll appreciate that.
Finally, on Friday night we met with our friend David Chelimsky for a night of conversation and brazilian music on a place called Revolver. It was the perfect night to close the conference.
We arrived a couple of days before the event, and left the Sunday after, so we had some free time to visit Chicago and enjoy some tourist stuff.
We started by visiting the Skydeck on Saturday night. It was a breathtaking view, I had never seen anything like that before, it’s super worth the visit.
On Sunday we went to the Navy Pier, and did the architectural tour. We spent almost 1h30 hour learning about Chicago, its architecture, the great fire, batman, transformers, and much more, definitely recommended.
After the Pier we decided to go to the Shedd Aquarium. Most of us had never been to an aquarium before, and it was such a great experience. You never know what you can find under the water, right?
We were very tired at this point but wanted more, so we went to the Adler Planetarium, which was unfortunately about to close – it was around 5PM. So we took a picture that could be easily transformed into a music album cover, and headed to a nice coffee place near the Millenium Park.
We couldn’t go back to the hotel without taking the famous picture on “The Bean” steel sculpture in the Millenium Park, so here it is:
Monday, the day before the conference, was marked by the visit to the Adler Planetarium (we made it!), which is a cool place to go if you enjoy such things as we do.
We also went to the Field Museum, which is another must place to go, where you can easily get lost in all those sections, it seems like a big maze, but it’s very enjoyable to walk through and learn more about all kinds of history. And we closed the day having dinner with some Rails Contributors and Basecamp folks.
Finally, on the Saturday after the conference we did some Shopping, and during the afternoon George and Lucas went to a Comic Conference that was happening in Chicago.
Besides that, I couldn’t end this post without commenting about the great breakfasts we had, I think I can say with certainty that we all particularly enjoyed these two places: Eggsperience Pancakes & Cafe and Meli Cafe. Definitely recommended.
There’s nothing like eggs & bacon to start your day :).
I hope I could show you at least a little bit how RailsConf was awesome for us. Conferences are always great to do networking, and RailsConf in particular allowed us to share and collaborate a lot with other people from the community. I like to think this is the main point of events like that, it’s where most of the good things come from, sharing and discussing ideas.
And Chicago is really a great city for tourism, there are lots of nice places to go, hopefully I will be able to go back there someday, visit some of these again and some other places, plus visiting some of the folks we met from Chicago would be cool too.
Here are the slides of my talk, Tricks that Rails didn’t tell you about:
I’ll update this post with the video as soon as it is online. In addition to that, we’ll be preparing another blog post with some of the talks we enjoyed the most after the videos are available, so we can link everything properly.
I want to thank again everyone that came to talk to me or tweeted about about my talk, I really appreciate every single feedback I’ve received. And also thanks to everyone who came to say thanks for our Open Source projects, we appreciate it a lot, it keeps us motivated to work more and more on these projects so that everyone can benefit from them.
How about you? Did you go to RailsConf? Did you enjoy it? Or are you planning to go next year? Remember, it’ll be in Atlanta, hopefully we’ll see you there.
Dave Thomas wrote a blog post called “Agile is dead (Long live agility)“. In the blog post, he claims the use of “do Agile right” as a way to profit, whereas it should make people – developers specially – to deliver valuable software more effectively.
It had a huge impact in the community in a way that many other people came up to point out their opinions. Also, some good texts about the subject came up as Andrew Binstock’s “The Corruption of Agile” and Allen Hollub’s “The Agile Holocracy“. In reply to the last two articles, Uncle Bob wrote “The True Corruption of Agile“. These are the kind of movement that make the industry to evolve: to criticize the “state of the art” practices and ideas. And to better understand what’s going on, it is better to step back and look for what “Agile” is supposed to mean. Watching a talk by Martin Fowler and Neil Ford called “Explaining Agile” can help us to better understand it. I’ll try to tr;dl the talk by Martin and Neil, so we can follow along with the discussion.
Before the whole Agile idea had emerged, industry majority used to follow waterfall by using frameworks and methodologies that support its idea, such as ISO 12207 and CMMI. All of them established a strict set of practices that should be followed in order to be compliant. The practices became a process and each person would take an input and then transform it into an output which would be someone’s else input.
And so did the tools, they were designed to support the same process for every company. Everything should be automated in such way that development pipeline (requirements, design, development, test, maintenance) would work perfectly. The only team with autonomy to change the process was the process quality team.
A successful project in waterfall would be one where everything run as planned. All people did was following the plan and making an input into an output hoping to get the final product at the end of the project.
It was noticed that the plan needed to be changed often during the course of the development and the later changes were needed the more expensive they would be. Although there are certainly exceptions, it’s usually very hard to plan a project and not needing to change it.
It would be better if the plan period was shorter and, by making it shorter, one could adjust the plan between periods. In order to make a good plan, review and retrospective meetings came up, so it would be easier to spot problems and to solve them. And to do so, it is necessary to give the autonomy to the team to change its own process independently of its project or organization unit.
That’s why “Agile” came for. We would have iterations and after each one we would have a chance to change the course of the project, to change the way software is being developed and to change the whole plan, so that we would have an empirical process/practices and not a strict defined process.
Where the corruption is
All the discussions raised by the cited articles are being fired by the same reason: “agile” is being misused. People are creating strict practices and process and taking it as “the right way” of developing software, whereas they should consider the empirical knowledge that each project gives as feedback.
It is needed to adjust the process and practices in a way it makes sense and turn the software development easier to maintain and faster to deliver value. In order to accomplish that, you have to change things. Embrace the change was not supposed to embrace only the requirements change, but any change.
People has turned Agile into a set of strict practices, when it is a philosophy/culture of how to react to environment stimuli. The practices are the reflex of the reaction and, biologically speaking – don’t forget software is built by living beings -, people can react differently for the same stimulus. And in this thought is where people is corrupting the agile.
I’ll give a real example to try to make myself clearer. When you work on different projects with different clients, the cultural differences among the stakeholders are more evident. So, it is our job to make the project to succeed and the way of doing that is adjusting the process over the time and don’t be afraid of doing new things.
For instance, I worked in a project once that was following Scrum guidelines. At some point, the plannings were not taking even a full hour. The stories were well defined: PO and the Scrum Master already had prioritized them before the planning had began. We used to estimate them before the meeting and the only discussions raised during the planning were about making sure developers had understood PO’s needs.
Because of that, in some retrospective meeting we decided to merge Kanban with Scrum and have something hybrid. We would still estimate the stories so we could keep the predictability, but we did not had plannings anymore. Bugs and User Stories were prioritized in the proper column and the developer would assign himself to the most prioritized one. Plan changes were notified by Campfire. When a doubt about the US was raised, Scrum Master and the assigned developer would talk directly with the PO using Google Hangouts and/or Campfire. The changes were communicated to the others developers through Pull Requests.
We got autonomy to change things and it was very satisfying to see the results. Always remember those left-sided values from the agile manifesto and let it flow. Remember that the process cannot decide how you work, but the other way around. We had delivered with agility, even though we took the risk of going out of the box and not being tied to the conventional practices.
Finally, I want to thank everyone who is helping to push the community forward by raising discussions like that. As always, when discussing, be aware that we criticize the practices themselves, not people or companies. There is no such thing as “right” or “wrong” for subjects like this, there is what works and what works better for you. So, what other practices can we discuss about? Have you done any change which had a huge impact? Share with us on the comments below.
The formal definition of estimate is “an approximate judgment or calculation of the value, amount, time or size of something”. In a software development project, estimates are important to help us predict how much time will be necessary in order to finish a set of activities, or to select and prioritize scope for a release or iteration.
It’s rather common on Agile projects that the estimates are done in a planning poker session. Each team member has a deck of cards with the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13), and for each user story (US), the team member privately selects one card to represent his or her estimate. All cards are then revealed at the same time. The estimates can represent story points, ideal days, or other units of cost that make sense to the project. Usually we use story points because we can consider three different aspects when estimating: complexity, effort, and risks. The story point unit allows us to more effectively capture sources of variation compared to an hour-based estimate.
Since story points are a relative measurement unit, the first step your team should take is to define one story as the baseline, so that they can estimate the other stories comparing to that reference. According to the literature, the team should find the simplest story in the backlog, and assign 1 story point to it, after that, they use that story as baseline to estimate the other stories.
However, here at Plataformatec we go a step further on defining that baseline story. We select at least one user story for each story point that we use, composing a “ruler score”.
In each sprint, we update the stories in the ruler with US’s of the previous sprint, so that when our team meets for the planning poker session, they have at least one baseline story on each story point to compare to.
Using that practice has brought us a lot of benefits, such as:
- The estimation process is more effective because the reference to each story point is clear, reducing the length of the discussion among the team;
- Even if the team has a new member, the story point variation is reduced because this practice enforces a reference to each story point in the “ruler score”;
- The team members have the same reference for each story point, preventing someone from having an implicit story point reference that is not shared among the others;
- On each sprint, the estimates becomes more and more stable, since using the ruler score guarantees that the story point references are always updated.
That’s it! We’d like to know what are your practices in estimating using story points. And if you try out the ruler score, let us know your results!