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!
We just released Simple Form 3.1.0.rc1 with support to Bootstrap 3.
To make it possible, we leveled up the Wrapper API to make it more extensible and to allow developers to directly configure it instead of relying on global state. After such improvements, it was very easy to change the Simple Form configuration to work with Bootstrap 3. I’ll talk more about this in a future post.
Integrating Bootstrap with Simple Form should be as easy as it was before. We are working on the documentation before the final release but you can find examples about how to integrate Simple Form with Bootstrap in our sample application. The app source code is available too.
Besides this main feature, Simple Form’s new 3.1.0 comes with a lot of enhancements. You can find the whole list of changes in the CHANGELOG file.
I hope you are excited about this release as much as we are. Please try out the release candidate and if you find an issue, report at the Simple Form issues tracker.
We plan to release the final version in a month or so, and we’ll write a new blog post with more details about Simple Form 3.1.
We, at Plataformatec, have worked hard to get this release out, with Lauro Caetano and Rafael França (it’s me!) working together on this final sprint. Also kudos to Gonzalo Rodríguez-Baltanás Díaz and the whole community for helping us to improve the sample application.
Rails 4.1 was just released this week and I already had a great experience trying out the release candidates on my latest project, so I decided to write a bit about my favorites features on this release and some things I have learned by using them so far.
Placing your configuration in a YAML file isn’t exactly a revolutionary feature, but the usage of the
config/secrets.yml file that comes with Rails 4.1 holds a more important idea: the promise of a default approach for environment aware custom configuration on Rails applications. Over the years the community created several ways to manage such configuration so every app out there deals with this differently, but now we can use the Rails default as a standard just like we do with the app folder or the routing patterns, taking the configuration madness outside the list of things to worry about when working with Rails. So instead of dealing with multiple YAML files or constants left out inside initializers, we can go with the
secrets.yml as the default for our apps.
Remember that you can place any kind of configuration – not just secrets like tokens or passwords – that need to be handled differently through your application environments, like API Endpoints or S3 bucket names. And for any gem maintainers out there, you can make your gem read these settings from the
secrets.yml automagically through an initializer block and maybe remove a configuration step from the gem setup. Adding this to Devise on this pull request was easier than I expected and I suggest you to try it out on your gems as well.
If you want to try to organize your configuration through the
secrets.yml without having to update to Rails 4.1 right now, Andrew White backported this feature on the rails-secrets gem for Rails 4.0 apps.
So, if you are dealing with some configuration mess or aren’t using something like dotenv for your application, I strongly suggest that you try to migrate your config to use the
secrets.yml file and see how it goes for your application.
2) Action Pack Variants
Variants are proving to be a great solution to render device specific views when mixed with any device detection solution like the useragent or browser gems, which you integrate quickly with just a
class ApplicationController < ActionController::Base before_action :set_variant private def set_variant if browser.tablet? request.variant = :tablet elsif browser.mobile? request.variant = :mobile else request.variant = :desktop end end end
Even though the main examples are dealing with User Agent sniffing, this feature can be used in any context where you want to have more control of which views are rendered by your application, like:
- A/B Testing different partials based on the user cookies.
- API versioning for your Jbuilder templates.
- Maintaining current and redesigned views for the same controller.
- Authorization aware views, like
In the end, Variants are just a way for you to have more control over how your views will be used by the app, helping you to remove boilerplate logic from your code and letting the framework handle it through a more elegant solution.
3) The improved cookies serializer
The changes on how Rails serializes cookies are a great improvement when it comes to security and stability of web apps. Before this, any object placed in the cookies Hash would be serialized (and deserialized) through
Marshal.load, which could possibly lead to remote code execution if an attacker got hold on your application secret.
Now this serializer is configurable through the
config.action_dispatch.cookies_serializer configuration option, and new apps will ship with a smarter default: a JSON serializer that won’t recreate complex objects besides Strings, Integers and other JSON data types. And for a smooth upgrade, you can use the
:hybrid serializer that will convert your existing marshalled cookies into JSON cookies, so this upgrade can be transparent for your application users.
This upgrade highlights a possible bad practice in our applications where we end up placing more complex objects in the session that can’t be completely restored by the JSON serializer, when we should be using more simple structures for the data stored in cookies. Thanks to a related issue reported on the Devise issue tracker we could simplify the gem code a bit, so instead of serializing
Time objects we could work with numbers.
So, when updating your application to use the
:hybrid serializer, don’t forget to do a double check of whatever kind of data the app stores in your users cookies and look for possible backwards incompatibility. And if you want to take a closer look on how this was implemented, be sure to check the related issues and pull requests on the Rails repo: #12881, #13692 and #13945.
Keeping up to date with the latest Rails changes
Following the activity on the Rails repository over GitHub helped a lot to understand better these features and the rationale behind their implementations, but going through all the commits and discussions on Issues and Pull Requests would demand a lot of your time. If you want some of the inside scoop but don’t have that much time to go through the Rails activity over the week, Godfrey Chan has put up a weekly digest about Rails named This Week in Rails. I suggest that you subscribe to the list and even check some of the previous editions on the archive page.
Try it yourself!
Take some time and upgrade one of your Rails 4 apps and try out some of the new features! I bet that some of them will help you improve your codebase or make your coworkers life a bit easier, and we are eager to hear from your experience with the 4.1 release.
TL;DR: test quality is not just about verifying correctly whether your code works, it’s also about making your test easy to read and understand. You can do that by structuring your test using the four-phases xUnit standard.
People don’t write tests to be read, they write them to be executed
One of the main reasons to write tests is to have an automated way to check if your code is doing what you expect it to do. That means, trying to verify its correctness. Your test suite acts as a safety net that guarantees your software will continue to work as expected while you refactor, build new features or fix bugs. That’s amazing! But, throughout the years, software developers discovered that tests can be even more than a safety net.
Write tests as examples of how to use your code
A test is an example of how to use your code, not just a way to verify its correctness. Seeing tests as examples of how to use your code changes a little bit the priorities you have when writing them. If the test should serve as an example, then it should be easy to read and understand. Therefore, you should also focus on test readability, not just test “executability” (I know, weird word). One way to improve readability of a piece of text (or code) is to write it in a way the readers are used to, a structure that they expect, some standard way… Let’s think about that.
Back at your school days, you learned that when writing an essay, you’re supposed to structure it in: introduction, body and conclusion. Why? Because that structure helps you to better express your ideas. That means, it helps the reader to understand your message. Is there any equivalent of that for automated tests writing? In fact, there is. It’s called the xUnit structure.
Structure your tests using the xUnit standard
First, let’s see a test that can have its readability improved:
describe Stack do describe "#push" do it "puts an element at the top of the stack" do stack = Stack.new stack.push(1) stack.push(2) expect(stack.top).to eq(2) end end end
One can understand the test above, but still, it’s not easy to quickly scan the test and see that it has logical parts. Those parts would be the the xUnit phases.
The standard xUnit test structure is composed of 4 phases: setup, exercise, verify and teardown.
- Setup: this where you put the object under test in the necessary state for the behavior you want to check;
- Exercise: when you send a message to your object;
- Verify: here, you should check if the object under test behaved the way you expected;
- Teardown: basically where you clean up stuff in order to get your system back to the initial state.
Now, let’s re-organize the test above making explicit that there are different logical parts:
describe Stack do describe "#push" do it "puts an element at the top of the stack" do # setup stack = Stack.new # exercise stack.push(1) stack.push(2) # verify expect(stack.top).to eq(2) end end end
It’s easier to scan, isn’t it?
About the comments, no, we don’t need them. I added them in order to make the example clear. Let’s remove them and keep this structure:
describe Stack do describe "#push" do it "puts an element at the top of the stack" do stack = Stack.new stack.push(1) stack.push(2) expect(stack.top).to eq(2) end end end
One can say that we just added two line breaks, that’s true. But that’s just the how, not the what. The what is: improving test readability. The how is: structuring the code based on the xUnit four-phase standard, by adding two line breaks. Got it?
Using a standard structure to ease the communication of an idea is not something new. As an example, Rails does that when it generates a standard directory structure. When entering on a new Rails project and scanning it, you know your way and where stuff are because you already expect a defined structure and you are used to it. It’s not something completely new, you’re used to that structure. I could also say that even Ruby uses that concept when it talks about the “principle of least surprise”, but maybe I would be going too far. So, let’s get that wrapped up.
Why care about test readability?
So, why should I care about all of that stuff? I mean, isn’t just having my test suite on green enough? No.
Test readability will be really important in a lot of situations. Like when a test gets red, someone needs to fix it. In order to do that, one needs to understand what the test is about. If the test is well structured and easy to read, they can fix it faster.
Also, if you think about your tests as examples of how to use your code, someone that is trying to use a class that you wrote, can see how it’s done in the tests. The test readability will be equally important here too.
So, what about you, how do you improve your test’s quality? How do you improve your test’s readability?
Every once in a while people ask us how we hire and interview software developers at Plataformatec. In this post, we share the key things we do when looking for and interviewing job candidates. We focused the post on actionable hints, from the basic tips up to some specific characteristics to the hiring process at Plataformatec. This is what has been working for us and we hope it is useful for you too.
Part One – define your Candidate Profile
Having a well defined candidate profile can save a lot of your time and is fairly simple to put together. A Candidate Profile makes easy for a non-technical person (an HR colleague for example) to help you find and identify potential candidates. These are some examples of what could be in your profile description:
- common “job titles” (specially if you are using LinkedIn Search to find candidates. ex.: software engineer, software craftsman, ruby developer, and so on)
- the most common skills
- their degrees and/or the universities the candidates went to
- their graduation year (if you’re looking for recent grads)
- companies they have worked for in the past
- also, it helps a lot to describe the things you are NOT looking for
But be careful not to make this list too long, it is supposed to be something simple to use. Our experience says that 4 to 5 characteristics are enough. If you want, you can download a Candidate Profile template at the end of this post.
Part Two – preparing your interview questions
The interview is a great opportunity for you to detect evidences (strong signals) that a candidate would be a great match with your team and that he/she is able to do the job… but you’ve got only 60min to do it. Wow, that’s hard! Where to start?
We’d suggest that you follow these steps:
1) Think about your company Culture and Values
- identify which behaviours…
- …reinforce your company culture
- …are definitely against your company culture
2) Think about the challenges of being in the role/job
- make a list of the key skills that the candidate must have to perform it’s activities
- describe a typical day of a person in this position
- think about the most difficult tasks this position requires
3) Focus on ‘how the candidate solves a problem’ rather than ‘the right answer’
- So, when building technical questions:
- avoid technical questions that are “right or wrong” type
- prefer questions where the candidate has to compare X and Y and present you good arguments (the pros and cons), ex.:
- “When would you recommend using X and when you would use Y?”
- we usually ask the candidates to criticize something that they really like, e.g.:
- “Tell me three things you don’t like about Ruby on Rails.”
4) Test your questions
- once you have finished writing your questions, ask them to yourself, to your colleagues or friends. Take notes about the type of answers you’re getting.
- remember, your job during the interview is to look for EVIDENCES, so if the answers you are getting are not providing you any evidences, then you need to refactor your questions.
Part Three – the interview
All right, you are about to finally meet with the candidate face to face. And if you’re using Skype or Google Hangouts please turn on your camera and ask the candidate to do the same. For the interview here are a few notes and reminders:
- Ice-breaking is important, and so is being nice. There’s high probability that the candidates will be nervous when the interview starts. So, the first step is to make them feel comfortable. This is good for them and for you too. If they feel comfortable, they will be able to be more authentic, show their real personalities. So, it is your job to turn the interview into a pleasant conversation. If the candidate is stressed during the whole interview you probably won’t be able to find any of your evidences.
- Pair-Interviewing. At Plataformatec, we like to interview candidates in pairs because we believe that two people can detect evidences better than just one. Usually one of us conduces most of the interview while the other pays close attention and takes notes. But try to avoid more than two interviewers as it could increase the stress level for the candidate and that wouldn’t help at all.
- The candidate should interview you too. Remember to spare a reasonable amount of time (preferably after you have asked your questions) to present your company to the candidate and to answer her/his questions. It is a respectful gesture. They have saved a few hours preparing and answering your questions and the least you can do is to return the gesture. And don’t forget that they are choosing where they want to work with you too. At Plataformatec, we feel that we had a good interview if the candidates leaves our office with more admiration and appraisal to our company’s culture, even if they are not moving on to the next steps of the hiring process.
- Look for for Cultural Fit evidences. As an interviewer, your job is to detect if there is a fit between the candidates and your company. Sometimes we hear from others interviewers comments like “We scared the sh#@ out of the candidate!”. That is a very corrosive attitude. Besides making candidates uncomfortable and being disrespectful, it is unlikely they will suggest your company to their colleagues.
Well, that’s it. I would love to hear your experiences in this topic and I wish you good luck in finding great teammates for your company!