Archive for 'agile'
Concise code: brevity and clarity
Posted on 20. Jun, 2011 by Guilherme Silveira.
A few years ago, with the wave of new (and old) languages growing its acceptance rate in the market, some people appeared defending code with the intention of being “concise”. Being concise means express a lot, with a few words; being clare and sucint; brief, but with all the required information; having characteristics of brevity [...]
Continue Reading
Effectiveness, knowledge and the progress curve
Posted on 02. Mar, 2011 by Guilherme Silveira and mauricioaniche.
In a recent post, Michael Feathers talked about the skill level in the software development industry. Knowledge requires practice and takes time to settle, so it is natural to see that, in a currently fast paced changing industry like ours, some individuals are amazingly away out of the mean quality. Feather suggests a graph showing [...]
Continue Reading
Driving design: adding a touch of our domain to our APIs
Posted on 21. Jan, 2011 by Guilherme Silveira.
In this second screencast from the Driving Design series, the amazingly simple form gem is shown along with a simple DSL implementation. Its current API uses a fluent interface through Ruby hashes that allows easy output customization. This is the current version of simple_form that allows one to configure the building process of a form: [...]
Continue Reading
Evolving software and improving algorithms
Posted on 13. Jan, 2011 by Guilherme Silveira.
Recently Bob Martin has posted a series of transformations that aid developers whilst implementing an algorithm. Following steps and in order to improve our code and achieve something is key to refactoring, TDD and other tools are out there that gives up that kind of feedback. Bob posts a few questions that are important for [...]
Continue Reading
Simple changes might not lead to simple solutions
Posted on 10. Jan, 2011 by mauricioaniche.
The process of delivering a new feature is consisted in implementing or fixing something that the current state is not capable of. Given the set of all problems that your software solves at this moment, there are many different ways to solve them. All of those possible solutions are valid and would end up in [...]
Continue Reading
Designing code: fluent interfaces and your domain
Posted on 03. Jan, 2011 by Guilherme Silveira.
Together with coworkers, we have been talking about the influence of Test First in our design: it is not only about testing, or testing all the time. The discussion is on how developers should learn from understanding feedback from every type of tests (unit, integration and so on) and act accordingly. We have begun a [...]
Continue Reading
Practice: Avoid guesses, do what is expected to be done
Posted on 11. Aug, 2010 by Guilherme Silveira.
Symptom: faced with two possibilities because the client did not let his desire clear enough, one path is chosen and it is often the wrong one. After delivering a new functionality, the client is the one who is going to test, approve and use it. Because it is difficult for developers to think as their [...]
Continue Reading
Practice: Favor finishing a story over starting a new one
Posted on 11. Jul, 2010 by Guilherme Silveira.
Symptom: Right before your development cycle finishes, which can be an iteration, a sprint or anything similar, all stories are marked as finished, giving a feeling of complete success. During the review meeting, when the Product Owner verifies what has been done, the number of approvals is extremely low: most of the stories are rejected. [...]
Continue Reading
When I am unable to TDD…
Posted on 24. Aug, 2009 by guilhermesilveira.
It has been a while since we started using unit tests (and other types of tests) in our projects. But test driven design has always been something that once in a while I feel unskilled enough to do from start!? Many people (including myself), for many reasons, that TDD is the way to go… but [...]
Continue Reading
small project + full time despair?
Posted on 16. Aug, 2009 by guilhermesilveira.
as a friend pointed out: “if you use a full time scrum master (in a small team), you do not need a scrum master, you need a gun”… if you need too much to sort things out, someone should take control and change everything…
SUBSCRIBE TO OUR RSS