Three Thinking Gems for Software Development Projects
Published February 5th, 2009 Under Quotes, Software Development | 2 Comments
I have just started reading the book “Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum” from Craig Larman and Bas Vodde. You will read the complete review later on this blog, but as the book is full of interesting wisdom from the beginning, I couldn’t resist to share some of them with you that you could apply quickly in you next project planning meeting.
“After working for some years in the domains of large, multisite, and offshore development, we have distilled our experience and advice down to the following: Don’t’ do it.”
“We regularly coach groups that ask, “How can we calculate how many people we will need?” Our suggestion is, “Start with a small group of great people, and only grow when it really starts to hurt.” That rarely happens.”
The last is taken from The Fifth Discipline: “Dividing an elephant in half does not produce two small elephants”
Sources:
“Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum”, Craig Larman & Bas Vodde, Addison -Wesley
“The Fifth Discipline”, Peter Senge, DoubleDay Business
Wise Iteration
Published March 20th, 2008 Under Quotes, Software Development | Comments Off
A you move ahead, keep in mind the following:
* Never confuse the map with the journey – The project plan is only an outline (and a guess at that), so you should believe the team’s results and not the plans. Remember, it is the achievement of the objectives that is important, not the production of artifacts or the completion of activities. Be careful not to confuse the ends (objectives) with the means (artifacts and activities).
* Adopt the attitude that continuous planning is a good thing – In every iteration, expect your plans to change (albeit in small ways if your planning is effective). Don’t fall into the trap of thinking that the plan is infallible.
* Mature your process alongside your team – Tune the working practices alongside the plans, adapt your team’s skills as necessary to improve over time.
* Be prepared to cut your losses – Canceling bad projects early is success because you save time, money and resources that can be applied to better opportunities.
* Be honest – Without objectivity and honesty, the project team is set up for failure, even if developing iteratively.
Transitioning from a traditional approach to iterative software development is more a change of mind than a schedule adjustment. So try to be honest… or at least as honest as you can be ;o)
The Three Rules of Test Driven Development
Published March 3rd, 2008 Under Quotes, Software Development | Comments Off
Over the years I have come to describe Test Driven Development in terms of three simple rules. They are:
1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
You must begin by writing a unit test for the functionality that you intend to write. But by rule 2, you can’t write very much of that unit test. As soon as the unit test code fails to compile, or fails an assertion, you must stop and write production code. But by rule 3 you can only write the production code that makes the test compile or pass, and no more.
If you think about this you will realize that you simply cannot write very much code at all without compiling and executing something. Indeed, this is really the point. In everything we do, whether writing tests, writing production code, or refactoring, we keep the system executing at all times. The time between running tests is on the order of seconds, or minutes. Even 10 minutes is too long.
Robert Martin
http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
Besides these rules and independently of an agile approach, I always like as a developer being able to verify quickly my code, because it makes much more easier to find all the errors I do ;o)
Sharing Trough Implementation Patterns
Published January 31st, 2008 Under Quotes, Software Development | Leave a Comment
The thing I like about the pattern form is that it gives you a way to talk about the motivation for what you are doing. So there is a lot of Java style books, and good ones, out there people with lots of experience, people who’ve thought carefully about how to program, but when I read them what I hear is a set of commandments, “Name variables like this, arrange your code like that, etc” and all those are good things to do in certain circumstances, but what doesn’t ever come true for me is why? What’s the context, what stage needs to be set before that’s the right thing to do, and what are the consequences? If I do that what other thing should I do so that the whole system works well together? So there are different personal styles.
People come to those styles because there are a bunch of decisions that work well together. Taking one bit of that out and using it isn’t necessarily working well. So by writing a pattern kind of format I get a chance to say: “How do you name fields?” Well, let’s see. What are all the things that you might want to communicate? What things might a reader be interested in if they are reading a name of a variable? What are all the constraints on naming, both in terms of like cognitive constraints. Abbreviations don’t work well for a variety of reasons, but why? Really long names don’t work well, but why? By writing in terms of patterns I get an opportunity to think about all of those. Here is my rule for naming variables, to use simple names that describe the role of the variable in the computation, but if I just said that as a commandment, someone could copy that, but they don’t really get it in the same sense that I care about, and more importantly when that is not the right rule, they don’t get any sense of what thinking was behind that rule, so they don’t know when to break it.
Source: “Kent Beck on Implementation Patterns” on infoq.com
The main point in Kent Beck’s words is that you cannot use software development methods and tools without knowing the context in which you should use them. Every time you find something interesting and new, you should ask yourself why and when you could use it, and why and when you should not use it.
Agile Software Development. Cooler Heads Must Prevail
Published January 11th, 2008 Under Quotes, Software Development | Leave a Comment
I have been distraught at the level of dogmatism, bigotry, contempt, or just plain ignorance that I witness in the agile world. I am not blaming the topnotch agilistas, though they sometimes, and just for effect in writings and presentations, reduce their messages to their essential bones, to the slogan level, and they omit the context—both source and applicability.
As agility is crossing the chasm, however—as you can see if you attend any big software synod such as SD East or West or OOPSLA (Object-Oriented Programming, Systems, Languages, and Applications)—many more people say (or repeat) rather uninformed messages with a strong conviction and little background, scoffing at anybody who dares to question their claims, even if it’s just a clarification about scope or context.
For writing these words, I’ll be shot dead as a traitor to the agilism cause, a defender of the waterfall church, a dinosaur, the über-curmudgeon, though I do value agility or agile practices in the proper context, and with the tainted glasses of my own 33-plus years of experience. But I would like my friends and colleagues to keep cooler heads, to question assumptions, not assume too much of a common, shared mental model, and contextualize what they hear, read, say, or write.
Source: Philippe Kruchten, Voyage in the Agile Memeplex
These are word of experience from Philippe Kruchten. It should be repeated that there is no silver bullet in software development and that many approaches will fail in specific contexts when their essence is not understood, but rather people are just trying to apply some recipes without intelligence and common sense. Every new approach will have its share of zealots that will apply them as strict religious rules. I am a strong believer that the success of software development depends more on adapting existing tools and processes to specific situations and not the contrary.
« go back — keep looking »