Eppur Si Muove

 
 
Scrum is very big in the company right now.  The teams that are able, all seem to want to transform into scrum teams.  Its a badge showing ones more forward thinking.  My wife herself moved to a scrum team two weeks ago and when I asked her what her experience was so far her response was 'scrum really really works'.  How should I take that considering that statistically speaking she's not pulling from a large data set?  Well, I know she has been interested in doing scrum for the past year or so.  Is the any confirmation bias going on there?
I have nothing against scrum but over the years I have worked on many projects, some as a developer, some as a lead, some using more agile methodologies, some using more formal methodologies.  There is no one right way to success and that is what I'm feeling these days as scrum is promoted as the answer, as  people focus on learning the one scrum way, the right way.  and, at the worst, as people look for the step by step scrum rules that they can follow to the letter.
My own team has been doing scrum for the past year.  And when I compare this team with all the teams and projects that I have seen over the past 11 years of development.  Scrum hasn't made this team more productive or more effective than the average.  Why is that? On one hand it matters who is on the team.  Are they effective? Do they have good judgement? Do they get stuff done? Do they get the right stuff done? Do they have foresight or are they reactive?  Good people are described positively by the answers to those questions.  And good people contribute effectively regardless of the official methodology that management endorses.  A second factor is the culture of a team.  Its hard to graft a series of practices on a team and have them result in anything different unless that team already has a potential to work with those practices.  To give a metaphor for this, the problem here is very much the same as a problem in developmental economics.  For some time economists have known that if one takes laws and systems from first world countries and transfer them to third world countries, the result is not a third world country that transforms into a first world country.  The result is no improvement.  Or putting the same idea in a more immediate context, the US can try bringing democracy and freedom to Iraq but Iraq still isn't going to be a beacon of freedom in the middle east.  It will end up being Iraq as its always been, and maybe a bit worse.  Good methods don't make effective teams; rather effective teams have good methods because there is an internal culture that promotes good methods intrinsically.
In all, just like its better to have societies with good rules, it better to have teams with good rules.  But the key is to have thoughtful people of like minds to guide themselves along because there are never enough rules to cover infinite, unexpected imperfections in the real world.  Good luck to those people who have found their scrum religion.  But for me, I just end up thinking of the words of Antione de Saint-Exupery - 'Every religion claims it knows how to make men but none can say in advance what kind of men it will make'.  And so it goes for methodologies and teams as well.

--Do your best - Marco
 
Im always experimenting; looking for ways to be a better developer.  Here are a few of the practices, that as I look back over the last 10 years, I feel have made me a more effective developer
1) tracer bullet design
When I'm thinking through a design I find that its really helpful to skip the UML diagrams and work out the design directly with a shell of empty code.  I will write the interfaces.  I put in some implementations but they will be just empty shells with no actual code realized yet.  This allows me to experiment with different naming conventions and see if I am communicating my intent through the language.  With code in place I can see how dependencies develop between modules.  Naturally, I can also compile my work as I go along as well.  Being able to compile helps me to catch any potential mistakes in my thinking; it holds me to a rigorous standard of correctness.  And lastly once I am done and satisfied with the design, I have code.  I may even have a build system in place.  Having code is a tangible result and that counts more to me than a set of pretty UML pictures.
2) Unit testing
People thing that unit testing is a practice that will decrease bugs in delivered code.  In my experience unit testing doesn't catch a lot of bugs.  Rather the main benefit from unit testing is that it has changed how I write code.  I have been forced to develop code that's more abstract and more configurable and less coupled because that style of code is the only code that can be tested easily.  On the same idea I find it very useful when learning a new language to do a lot of testing .  Testing provides quick feedback which is nice for learning; it also forces one to learn the idioms that language provides for abstraction.  Lastly, I should also mention that an important benefit from writing unit tests and having good code coverage, is that one can refactor with confidence when ones application has to undergo change.  Without that coverage there is no way to rework code with confidence on a large project -- one is stuck with the past and trying to money patch as one goes along.
3) Design by Contract
Its really hard to write correct code and write robust code.  Thinking in terms of preconditions / postconditions / invariants, adding asserts to code, has all helped me to write correctly working code the first time through.  I also find that thinking in terms of DBC, along with unit testing,  changes ones thinking towards a more specification oriented frame of mind.  The thinking is more rigorous, that influence works it way down to the code.
4) Dynamic Languages
For fast development go with a dynamic language, an IDE that supports that language and a debugger.  As an example, I worked on a supporting tool for our main project at work using Groovy in Eclipse.  The tool was of fair complexity and it was finished in a week.  Comparing the development speed to comparable tools I have written in Java, I would say I was at LEAST twice as productive working in Groovy and there were no negative effects in other areas.  That said, I'll just emphasize the productivity seems to be not just a function of a dynamic language alone.  I also develop for my own pleasure in Clojure / Slime and I don't see the productivity gains there.  I've done a fair amount of Perl in emacs; good productivity but no huge gains there.  Also, as a slightly non topical reference point, I haven't seem much in the way of gains using Haskell in emacs.  My explanation is that using dynamic language along with the full support of an IDE sets the basis for remarkable productivity gains from day one of working with that language. 
And you? What practices have been valuable to you as a developer?