Martin Fowler strikes back with his intriguing ideas on Design and Architecture. In the last entry, I went over how Fowler had entertained the thought that, perhaps Architecture will not be needed if agile development methods are employed. In this entry, I'll review his fresh take on declaring design deceased by way of X-treme Programming (Lighting strikes in the background).
So now, we face the music, either we drop design or we don't. In traditional fields, like building architecture, we can't do that, not by a long shot. Builders don't ask "How high do we keep going?" And architects can't answer, "Until it topples, then we fix it." In software, it's more possible. We can code from scratch and keep adding features as we need them. There is a catch, though. Errors and bugs can become accumulative and the cost of fixing them rises as the embed themselves into the inner roots of the program. This turns into pretty much a back and forth discussion.
So do we design for software?
Well, we can't foresee everything, and eventually things will pop up that will requiere re-designing.
Do we design with flexibility?
Yeah, but flexibility where? The need for changes might pop up anywhere. You'll need a good understanding of the software requirements. If they don't change, that is...
Overall, I find the purpose of this essay by Fowler to be very back and forth to prove the point that it is possible to achieve a hybrid "planned" and "code-and-fix" approach. In the end, design might not be dead, but with agile workflows, we can reduce its importance. A few key takeaways for me are to focus on what's needed, do not code for what's to come, if a module is important, then let it grow, but only if it's needed. Ensuring a high quality coding standard and following best practices also goes a long way.
So now, we face the music, either we drop design or we don't. In traditional fields, like building architecture, we can't do that, not by a long shot. Builders don't ask "How high do we keep going?" And architects can't answer, "Until it topples, then we fix it." In software, it's more possible. We can code from scratch and keep adding features as we need them. There is a catch, though. Errors and bugs can become accumulative and the cost of fixing them rises as the embed themselves into the inner roots of the program. This turns into pretty much a back and forth discussion.
So do we design for software?
Well, we can't foresee everything, and eventually things will pop up that will requiere re-designing.
Do we design with flexibility?
Yeah, but flexibility where? The need for changes might pop up anywhere. You'll need a good understanding of the software requirements. If they don't change, that is...
Overall, I find the purpose of this essay by Fowler to be very back and forth to prove the point that it is possible to achieve a hybrid "planned" and "code-and-fix" approach. In the end, design might not be dead, but with agile workflows, we can reduce its importance. A few key takeaways for me are to focus on what's needed, do not code for what's to come, if a module is important, then let it grow, but only if it's needed. Ensuring a high quality coding standard and following best practices also goes a long way.
Comments
Post a Comment