Skip to main content

Is Design Dead?

 This week, we had to read Is Design Dead? by Martin Fowler. Just by reading the title, the thought of agile methodologies popped into my head, since they do involve design, just not as much as we're accustomed to. And not too surprisingly, Fowler reached a similar conclusion: design is NOT dead, it has just evolved along with us to keep up with today's standards. 

Before, design was used to make sure that you knew everything you needed to get done, and it let you find any flaws in your plan beforehand. It was meant as an all-encapsulating process that all future code will be based on. Today, it has maintained its role as a guide, as to not make the developer feel totally lost, but with today's fast-paced work environment and ever-changing requirements, with the help of methodologies such as Extreme Programming, it has evolved to become more dynamic and easier to change. 

For my personal opinion, I've had experiences (both academic and professional) where a bit of design, or just an idea of what the final product would look like, would've saved me (and my team) a bit of a headache. However, I've also been on the other side. While a too-thorough design has never been an issue in the sense that it's stopped our workflow, it has slowed us down, because going back to change the documentation and redesign future steps after a small change is very counterproductive. 

I'm very aware that there is more than one right answer (which is not the same as saying there are no wrong answers, because there certainly are), and that how much effort you put into the design fully depends on the scope and type of project you're developing. As is almost always the case, in most instances, the answer will lie somewhere in the middle; it's definitely not a good idea to begin a project without any design at all, but we should also be aware that it shouldn't shape our future decisions if it makes sense for something to change, and knowing when it's right to change our design will only come with experience.

Comments

Popular posts from this blog

Why is an architect?

  This week's (very short) article, Who Needs an Architect?, Martin Fowler explains to us the different definitions of architects that exist in the software world. The first and most common definition, which Fowler disagrees with, says that an architect is (s)he who helps identify what the most important parts of a project are, in order to give it structure. However, it is also mentioned that these parts are usually the most important because they are the hardest to change, so an architect's job should also include reducing the amount of these parts. Following the logic, by this definition, an architect's job is to reduce the amount of architecture.  The second proposed definition, which I also think I agree with, is that an architect's role is more like a guide's. His purpose is to help the team become better by using his expertise, and communicating with as much of the team as possible in order to remove their blocks. I think the word architect  still fulfills thi...

Man on the Moon

The third episode of Moon Machines, titled  Navigation Computer  tells us all about the process of building the Apollo Guidance Computer. It amazes me the amount of work that goes into a project of this size, and it has always surprised me how many people don't care about space travel, or even the amount of people who, despite seeing all the people involved and all the hard work, still deny the moon landing ever happened.  I also found it really interesting how seemingly unorganized MIT's software team was while working on this project. This isn't meant as a jab at them, but the fact that one of today's most prestigious institutions didn't have a well-defined plan speaks of how much project management and software development in general have evolved in such little time.  However, it's also funny to see how little things have changed in that regard, in the sense that even today, the amount of work that goes into developing software is grossly underestimated (even...