In a previous post I commented about Fred Brooks’ great conference when he received the Turing Award. He named it “The Design of Design”. In that conference he spends a lot of time discussing life cycle models and explaining why the Waterfall model is wrong (“dead wrong” as he calls it). And he also presented what he thought was a better model: the co-evolutionary model, attributing it to Maher and Cross. In this model, from a Problem P1 you get a Solution S1. And from P1 and S1 you get a new problem, P2. And from P2 and S1 you get a new Solution, S2. This simple concept explains that the problem and the solution evolve in parallel. And it’s one of the good things that Agile Methods have adopted. If you use agile methods, your lifecycle model is not only iterative and incremental. It’s also co-evolutionary. Let me explain this better.
Co-evolution – Brooks did it again
Posted on October 21st, 2009 by Santiago CeriaSignificant Design Up Front, When?
Posted on August 25th, 2009 by Santiago CeriaSo in my previous post I said that nowadays there are fewer cases when building models before building the actual code of an application makes sense. In which cases does it make sense? More explicitly, in which cases should we spend a significant amount of time creating architecture and design models before we run to code? Let’s ignore for a while safety critical applications and “for other reasons very critical applications”, the easy answer to the question (I know that more and more applications are becoming critical, but still I want to focus on the other ones, at least for this post). My question is equivalent to asking “when do we need significant design up front”?
Team Foundation Server from within Eclipse
Posted on August 4th, 2009 by HATI was trying to integrate a Java project with TFS, using Eclipse and Teamprise. Teamprise is a suite of client applications that includes an Eclipse plug-in for accessing Team Foundation Server.
In general the plug-in works remarkably well (in fact, I think it works better than Visual Studio with Team Explorer!). It’s really stable (thanks to Eclipse) and several options are easier to access than in Visual Studio.
Pros
Integration with the source repository is complete and limited only by TFS (you can still use the Team Synchronizing perspective or you can use the new ‘Pending Changes’ view). Some particularly interesting characteristics are the shelving feature, check-in policies, and the ability to associate changesets with specific tasks, bugs or any other work item type, providing a higher level of traceability. You can develop and deploy your own policies, although you have to install them in all clients.
A change in focus for Software Engineering
Posted on July 29th, 2009 by Santiago Ceria
My friend Hernán Wilkinson sent me a link to a blog post that included a reference to a very interesting article by Tom DeMarco. Just as a reference, De Marco is one of the classic authors in Software Engineering. When I studied systems analysis more than 20 years ago, his book on Structured Design was like a Bible.
I agree with almost everything he says there, but still I think that he takes it too hard against his own work, and I want to relate this to my previous post, because what he proposed in “Controlling Software Projects” is something that even in 1982 didn’t work in all software development projects, although from what he says it looks like he didn’t realize that at that time. But the key is that they worked in many software projects: in the types of projects that DeMarco was involved in then. So, probably his mistake was not to mention in what types of software development projects the techniques he was proposing had proved to be effective or were important in relation to what they were trying to achieve. Also, it’s easy to say now that some things proposed 27 years ago are not true anymore. Just as an example, “The Mythical Man Month“, Brook’s classic essays book that is a must for any software professional, has many things that are plain wrong if tried to applied nowadays, as Brooks himself recognized when he said “Parnas was right, I was wrong”.
Why do we keep searching for unifying theories for software development?
Posted on June 29th, 2009 by Santiago CeriaI want to come back to the discussion about Agile vs. CMMI. After a presentation about the subject in UTN (National Technological University) in Córdoba a couple of weeks ago, I started thinking a bit differently on the subject. I thought that instead of asking the question “Are CMMI and Agile Methods compatible” the important question is “Should CMMI and Agile Methods be compatible?”
In other words, if they are not compatible, so what? Isn’t software development an incredibly wide field so as to need different approaches to different problems? Didn’t for example Management benefit during its evolution from new theories that presented different points of view about how organizations should be managed? CMMI and Agile methods present many incompatibilities (at the CMMI practice level and not at the goal level), and one of the reasons is that they follow different management theories.