tagged by: process theory
In the past few years there's been a blossoming of a new style of software methodology - referred to as agile methods. Alternatively characterized as an antidote to bureaucracy or a license to hack they've stirred up interest all over the software landscape. In this essay I explore the reasons for agile methods, focusing not so much on their weight but on their adaptive nature and their people-first orientation.
13 December 2005
by Jonathan Rasmusson and Jim McDonald
As XP and other Agile methods gain popularity, questions are beginning to surface regarding how to scale XP beyond teams of 10-12 people. In mid February 2003 a workshop dedicated to the subject was held in Banff Alberta Canada. In this article we report on the keynote speeches from Ken Schwaber, and Martin Fowler, as well as other leading practitioners.
There are various schemes of Code Ownership that I've come across. I put them into three broad categories:
12 May 2006
From time to time I have indirect conversations about whether good software design is a worthwhile activity. I say these conversations are indirect because I don't think I've ever come across someone saying that software design is pointless. Usually it's expressed in a form like "we really need to move fast to make our target next year so we are reducing <some design activity>".
20 June 2007
One of two SoftwareDevelopmentAttitudes.The enabling attitude takes the view that developers are responsible professionals and so should be given the freedom to do whatever they need to do. Designs that follow this attitude should make things easy to use well but should assume that developers know what they are doing and thus not try hard to prevent something being used badly. As such these tools can be misused, but take the attitude that users should know better, and if they don't they deserve all they get.
A common, perhaps dominant, practice of agile methods is to develop a list of features (often called stories) for the software that's being built. These features are tracked with index cards, work queues, burndown charts, backlogs, or whatever your tool of choice is.
2 November 2006
A maturity model is a tool that helps people assess the current effectiveness of a person or group and supports figuring out what capabilities they need to acquire next in order to improve their performance. In many circles maturity models have gained a bad reputation, but although they can easily be misused, in proper hands they can be helpful.
26 August 2014
One of the most difficult things for many people to understand about agile methods is the people orientation of agile. Those who are interested in agile processes all agree that process is a second-order effect on project success. The first value of the agile manifesto is that Individuals and Interactions are more valuable than Process and Tools.
12 January 2004
You're sitting in a meeting, contemplating the code that your team has been working on for the last couple of years. You've come to the decision that the best thing you can do now is to throw away all that code, and rebuild on a totally new architecture. How does that make you feel about that doomed code, about the time you spent working on it, about the decisions you made all that time ago?
20 October 2014
SEMAT (Software Engineering Method and Theory) is an effort initiated by Ivar Jacobson, Bertrand Meyer, and Richard Soley. Its stated aim is to "refound software engineering based on a solid theory, proven principles and best practices". Like many notorious people in the software world I was invited to participate. Thus far I've declined and feel the need to explain why.
16 April 2010
Many debates in software development are underpinned by whether the speaker has a DirectingAttitude or an EnablingAttitude. These different attitudes affect choices over languages, designs, tools, processes, and lots more.
8 March 2004
This is the month for review of the IEEE's Software Engineering Book of Knowledge. This is an attempt to define the body of knowledge of our profession, in a way that can lay the groundwork for a licensed profession.
24 June 2003
CHAOS report says only 34% of projects succeed.
The Standish Group's CHAOS report has been talking of billions of wasted dollars on IT projects for many years. The 34% success rate is actually a improvement over 2001's figure of 28%. But what do we really mean by 'failure'?
15 May 2003
by Diana Larsen and James Shore
Agile methods are solidly in the mainstream, but that popularity hasn't been without its problems. Organizational leaders are complaining that they're not getting the benefits from Agile they expected. This article presents a model of Agile fluency that will help you achieve Agile's benefits. Fluency evolves through four distinct stages, each with its own benefits, costs of adoption, and key metrics.
8 August 2012
When people use the term 'software architect' they are using a metaphor from building construction to help people understand the architect's role.Ironically in doing this they misunderstand the actual role of a building architect.
14 August 2003
Dan North's recent blog post on software craftsmanship has unleashed a lot of blog discussions (which I summarize below, if you're interested). There's a lot in there, but one of his themes particularly resonated with me, hence this post.
19 January 2011
One of two SoftwareDevelopmentAttitudes. The directing attitude says that since most developers aren't that good (it's rumored that almost 50% are below average) we need to direct the way they do things. This direction is to prevent them from causing harm to the system they are working on. Typically this attitude manifests itself in designs and tools that prevent developers from doing certain things, limiting what they can do to keep them away from complex areas.
My main inspiration in life is trying to capture and improve the way in which we do software development. So I spend a lot of time talking to people about various techniques they've used, which ones work well and which ones suck.
As I do this, I often hear about faulty techniques: "FIT wasn't worth the effort", "never put any logic in stored procedures", "test driven design led to a chaotic mess". The problem with any report of a faulty technique is to figure out if the technique itself is faulty, or whether the application of the technique was faulty.
5 August 2004
One of my favorite soundbites is: if it hurts, do it more often. It has the happy property of seeming nonsensical on the surface, but yielding some valuable meaning when you dig deeper
28 July 2011
As regular readers of my work may know, I'm very suspicious of using metaphors of other professions to reason about software development. In particular, I believe the engineering metaphor has done our profession damage - in that it has encouraged the notion of separating design from construction.
As I was hanging around our London office, this issue came up in the context of Lean Manufacturing, a metaphor that's used quite often in agile circles - particularly by the Poppendiecks. If I don't like metaphoric reasoning from civil engineering, do I like it more from lean manufacturing?
16 December 2004
For as long as I've been in software there's been a debate between FunctionalStaffOrganization and TechnicalStaffOrganization. The debate occurs within project teams, and across whole IT organizations. It's a constant debate because both sides have good logical arguments to support them, and there's no real way to test which has an advantage in practice.
2 August 2004
For nth, and I'm sure not last time, I'm sliding into a conversation about defining practices, labeling some of them as "best", and probably the C-word (certification). It's a familiar discussion, and although we've barely started it, I can predict much of where it will go. It's driven by a perfectly reasonable desire to identify who are the better software developers, and how existing developers can improve their abilities.
12 April 2008
Shu-Ha-Ri is a way of thinking about how you learn a technique. The name comes from Japanese martial arts (particularly Aikido), and Alistair Cockburn introduced it as a way of thinking about learning techniques and methodologies for software development.
22 August 2014
From time to time people question whether a particular specialty can be used incremental way: "You can't do (security | user interface design | databases | internationalization | * ) with an agile project because this aspect has to be done up front."
5 January 2005
One of the steady themes I've seen throughout my career is that of the nature and importance of software development. A few years ago a prospect told one of our salespeople that "software is like sewage pipes, I want it to work reliably and I don't want to know about the details". This is the kind of approach that Nicholas Carr talked about in IT Doesn't Matter. On a contrasting note we've done work for many businesses where IT has been a clearer strategic enabler to their business, allowing them to enter new markets or significantly increase their market share. So is IT a utility, like sewage pipes, or a strategic asset?
29 July 2010
Yagni originally is an acronym that stands for "You Aren't Gonna Need It". It is a mantra from ExtremeProgramming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need it".
26 May 2015