Adam Bien's Weblog

Should beginner read the agile manifesto (or a scrum/xp/tdd book) or a good java (or ruby,c#, groovy) book first? It seems like more and more people are interesting in more soft, than technology topics.
It would be interesting to do the following experiment: Just observe a novice, but passionate, developer how he (perhaps she) learns the technology. The developer shouldn't have any knowledge about processes, especially agility, lean development or XP. I remember the time, as I started with C++, then Java. In both languages I first implemented a hello world sample, compiled and ran it. Then I played with another samples. I deployed the software after the implementation of an every new feature. The reason: I was curious about the results and a littlle bit afraid of the complexity. Even in my first projects we deployed our software several times a day to the target environment (it was an orbix orb), because it was too complex to deploy the software in longer cycles and the software was really buggy. The developer support wasn't comparable with current IDEs, there was no integration server etc. We didn't used JUnit (it wasn't avaible), but we tested the business logic with some main-methods.
I also worked in parallel with some database exports, often on one machine. I wanted to understand what's going on in the DB. It was a kind of pair programmig, but not the whole time.
I observed my young brother, as he learned programming some years ago, and it was also very iterative if not agile. So I started programming, without any knowledge, in more or less agile while (with a bad feeling, because I wasn't able to design in UML the whole application at the beginning of a project). I also observed my students in trainings with similar results.
My assumption:  If someone is really interesting in the technology or application, and tries to achieve some results, he will probably go the agile way.
I think it is more important to train management or even organizations, than developers to be agile.
Developers also tend to become a little bit dogmatic, after some agile courses or workshops - which is not very efficient in software development. I think the customer and the product (system) and not the process or even technology should be emphasized. But it is hard to build a system only knowing the process and not the technology :-).
It is also very hard, if not impossible, to describe the agile processes, because of the agility :-). In case it is written down it gets a dogmatic touch and developers try to follow hard rules, which is no more agile... Also the naming is cool but confusing (ScrumMaster, standup meetings, in zone, pair programming etc.). Just imagine: you have a team with experienced and motivated developers - is it still needed to talk about iterations etc.? At the other side: in case your developers are not interested in the software they build - do the agile process really help?
I think every developer should now about the processes. Every process has some advantages and trade-offs. But we should not overestimate the soft and process skills. The developers have still to code the software...

Posted at 12:39PM Aug 02, 2006 by Adam Bien in Enterprise Architekturen, Leitfaden für Effiziente Softwareentwicklung  |  Kommentare[4]

[my tweets]  Rss My book: Real World Java EE - Rethinking Best Practices