I’m not known for going to conferences very often, so this year I will do something very special: Attending two conferences! PHP Unconference in September was great fun already. The other one will be Developer Conference in Hamburg, which starts in two days. I know some of the speakers personally (the list is actually quite impressive) and I look forward to see them again. Even Professor Lutz Prechelt will give a talk.
Many of today’s agile software projects are characterized by a lack of written requirements and other documentation. The rationale behind this is that requirements change “too often” to be written down. Project management might also be afraid that writing documents consumes too much time of developers and stakeholders. However, my personal experience is that projects with clearly defined and written requirements run much smoother and have less delays. Written documents are forcing developers to think and clarify open issues before they start coding.
How reliable, useful and realistic are effort estimations and what are the implications of different methodologies? Since at least the 1960s, this is a hot topic for software engineers and their managers, although the importance of precise estimation is decreasing in the age of agile development. I would like to give a summary of my past experiences, some recommendations and point to scientific research. Judgement-based effort estimation is on average at least as accurate as formal estimation models, so I’m not covering any formal methods in this blog post.
If there is one work-related term that got stuck in my head it is “cargo cult“: In the South Seas there is a cargo cult of people. During the war they saw airplanes with lots of good materials, and they want the same thing to happen now. So they’ve arranged to make things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head for headphones and bars of bamboo sticking out like antennas—he’s the controller—and they wait for the airplanes to land.
In contrast to some discussions we observe in the software community, agile development is not about cargo cult adoption of Scrum or any other process, toolkit, or methodology — although we certainly observe this and consider it a problem. The essence of agility is responsiveness, learning, and sufficiency. Agility is reflected in sustainability and quality in software and its development — by definition, unsustainable and poor-quality development contradict and reduce agility.
Most teams purporting to be doing agile software development are not applying the level of technical rigor necessary to succeed at it. Most “agile” teams have actually only adopted Scrum’s project-management practices and have failed to effectively adopt “the hard disciplines” like test-driven development, refactoring, pair programming, simple design, and continuous integration. Jean-Raymond Abrial, Faultless systems: Yes we can!, IEEE Computer 9⁄2009
A posting in the Agile and Lean Software Development group on LinkedIn inspired me to think about the amount and type of documentation that should be created in agile projects. It is a misconception, if developers think that agile methods do not require any written documents. Here are a few (I think the most important) examples: A Wiki that contains the steps required to set up the application and a list of config files and config options can be considered essencial documentation – especially for developers who join the project at a later time.
There’s a misconception about responsibility that probably starts to establish in our brains during childhood. When we grow up, we get taught that responsibility means to follow the established rules of society (including our parents and the various educational institutions), which indeed is a good start. Now, the challenges we face in large software projects are much more complex and dynamic. The solutions can not be found in simple rules like doing your homework every day.
For years, I was arguing against the believe that agile teams are actually self-organizing (like a flock of birds), because every practitioner knows that there is a lot of active organization and planing needed for a software project to be successful – especially in agile environments. If the management doesn’t care, the team will barely feel the need to organize anything. From the business perspective you want to have clear responsibilities as well and not a situation where “everybody and no one” is responsible.
Nevertheless, in spite of such helpful articles and many textbooks on software design, software jewels remain rare. Most of the software we see or buy is ugly, unreliable, hard to change, and certainly not something that [Niklaus] Wirth or [Edsger] Dijkstra would admire. If published papers contain the secret of success for software, shouldn’t we see more jewels? David Lorge Parnas, Why Software Jewels Are Rare, IEEE Computer, February 1996