One of the most intriguing parts of the discussion, that was part of my speech in IAD2008, was a question (interestingly asked by one of the few non-developers) regarding possible negative effects of time-boxing (especially in the form of “pomodoro”) on a creative activity such as developing software.
I quickly dropped my opinion, but I was more interested in making others opinion on the topic emerge. Then I had some tome to think better about it: here are my thoughts.
Coding is not a creative activity
I mean ...there’s creativity involved, but most of the time we are solving problems, in ways which are probably been explored by many others before us. So, basically, coding is a problem solving activity. Creativity slips in when the problem to solve is new, non conventional or pretty hard, or does not strictly involve coding (in this respect, the process might be far more creative than coding). Sometimes we have the luck to deal with applications which are pioneering, but many more times, this is not the case.
This doesn’t mean that we have to be mere follower’s of somebody’s else ideas. But “being creative” or pretending to be, too often has the undesirable side effect of “reinventing the wheel” which is definitely not what we want. Put in another way, “being creative” is often just an excuse for being “too lazy to study”.
Time-boxing does not constrain creativity
Ok, then there are times where the strict time constraints imposed by time-boxed activity, a pairing session, a pomodoro, a day or a sprint, is not enough to allow for the “inspired” solution. As Simone Genini pointed out, “as a manager, you don’t want to wait for developer’s inspiration”. So what you need is a repeatable attitude for this problem solving activity.
Back home I realized that this happens in creative fields too: comics are written on a monthly basis (even if not every author can fit in the schedule), ad campaigns are creative, but organized as time-boxed projects, and so on.
Even in software development, the time-box constraint is less stringent than it might be: if one of your best developers came out with what he consider a sub-optimal solution, something he doesn’t really like. You can be sure that he’ll keep thinking about it, and probably will attack the problem again, once a better solution appeared to him in his dreams or under the shower. Just allowing more coding time to be explicitly allocated to that task won’t probably get the solution any closer.
3 comments:
I'm "the one" guy who raised the question.
What i meant with my provocation was to instill a doubt about the fact that a risk of certain agile methodologies is to "box" not only time, but persons.
Seems to me that there is a great risk to leave out certain aspect of human beings (creativity, instinct, passion) making the software developer a robot, just an executor of well-defined (pre-defined??) methods.
What i meant was (and I'm still provoking, obvious): can you imagine Monet or Caravaggio or Pollock using the "pomodoro" as a working method?
So, don't you feel the risk that such a controlled ambient, that doesn't leave any space to the unpredictable, can also kill the "genius" that is every person?
For the "Coding is not a creative activity" part: I'm glad I'm not the only one to have this (unpopular, I'd say) opinion.
Developing software is a rather simple activity: you have to know the rules, and apply them.
Unfortunately, there's still a considerable part of managers/developers that doesn't spend enough time to learn the rules (or pretend not to need them), and that's why the "software/creative activity" misconception is still there.
@Cristiano
Hi! I really liked the provocation, you hit a sweet spot there!
There are projects and projects (my next post will dig deeper on the matter... this one is somewhat sad). But many times, what you have to solve at coding level is a puzzle that needs a smart solution, but not necessarily a "creative" one.
Feeling free to unleash the artistic part of yourself is not a "professional attitude". I remember counting the number of significant bugs I introduced in one of my first projects. They were not many, but I still remember how "inspired" I felt when I thought I had this "great idea", that was actually ...crap.
But software is not art. Every project is constrained by time and budget, and also by being in a team. Being the "damned artist" of the team could severely hurt your team's alchemy. There are a lot of "wanna-be-genius" developers, compared to the real ones. And they can be a real problem, sometimes.
@ Filippo
Hi!
Well, this is only one side of the coin. If the rules are that simple, you'd probably have to use a different way to make software, instead of humans.
I just think that coding is not the best place to express creativity, but applying this to software development in general is probably going too far, and is definitely not my intention. Coding is solving puzzles. There is a lot more of creativity in investigating and defining what the problem is, and also in deciding howthese activities have to be performed. In this sense, Agility brought creativity within the process itself (could you do that in UP?), but running too fast in that direction, could lead you to non-passionate developers, non-interesting projectsin a vicious spiral.
best regards.
P.S. I published this on my blog, to have it open to the "outside world", but we could also have this discussion on the agilemovement website, if you want. :-)
Post a Comment