Design Is Difficult

Most of the design problems I've seen over the years boil down to the simple fact that no one put any thought into the design. Programmers who came after the original designer preferred to perpetuate the original design atrocities rather than stop and think, "Hmm. You know, if I make some changes here and here, this will be much more maintainable in the future."

Many of the designs I've run across over the years were written by people who didn't even understand simple data structures or how to program for that matter. This despite apparently having degrees in the field. Probably MIS degrees. I don't see how you could go through four years of CS without knowing how to malloc (though it may have something to do with university professors not knowing how to malloc, or not being rewarded for that knowledge if they do).

So far, this doesn't address DesignIsDifficult so much as "many software people don't learn how to do design" and "many software people don't put sufficient effort into design."

Design is not difficult. Procedural design is not difficult. Object oriented design is not difficult. Stopping and actually thinking about how to best approach the problem at hand what tools you have at your disposal to solve it is difficult. Or at least, it seems like too much of an effort for most of the programmers I've ever encountered.

I think design IS difficult, and that is part of why many programmers shirk the duty. People tend to avoid that which is hard or poorly understood...

What I'm trying to say, in a nutshell, is don't just dive right in. Pause. Think. Yes, you have deadlines. Yes, they're coming up fast, but if you make just a little more of an effort now, maybe three years from now when you've got another deadline coming up and you haven't looked at that hunk of code for three years, you'll thank yourself for putting a little extra thought into your design. (Does this go against YouArentGoingToNeedIt?)

-- BruceIde

"thinking about how to best approach the problem at hand [with] what tools you have at your disposal to solve it is difficult" Am I missing something? Does this phrase not exactly state "design is difficult"?

We are in the habit of writing programs for which small changes create obscure problems and thus large delays. In such an environment, any progress is difficult. This site is dedicated to the patterns and practices that overcome this habit. Constructive suggestions are encouraged.

It is relatively easy to get something up and running that serves some limited, immediate function. You may not need much of a "design" at all; you cobble together a prototype, you refactor it as you add more functionality, etc. But if you also have a goal of having this software be flexible - growable to handle new requirements, upgradable to take advantage of new technology (OS, libraries, products, etc.), able to interface with other systems/software, customizable by the user, and so on - then your task can become very difficult. You really have to craft a solid, resilient design, and depending on your circumstances this can take plenty of effort, or lots of experience, or both. Change is inevitable, and much current software is fragile, does not handle change well...

I think it is because of the nature of the project. If the project is to develop a product which you yourself have to maintain, designers put some effort. If it's a project that is handed over to the client, then not much good design goes into it. The real reason is who is responsible for maintenance.

The main problem I see is that many people don't define the design goals; software can be designed for scalability, or can be designed for reuse, or can be designed for maintainability or for other characteristics that are more appropriate for the project. Design is a balancing act of the above goals, where you define what is more important to you in your project. And to achieve these goals within the time constraints and with resource (knowledge, language and personal etc) restrictions is a difficult thing. --SeshKumar

Aha! Sesh is onto something here. Coming up with design ideas is not usually difficult, but evaluating them in the abstract is. What's particularly hard for groups I've observed is trading off the pros and cons of "this design" versus "that design". And the problem underlying that is the absence of goals that are specific enough to support the tradeoff process. It comes down to slack requirements work, because that's where the goals are set. But even when the goals exist, quantifying pros and cons for precise tradeoff analysis is difficult and meets resistance. -- WaldenMathews

I am thinking about refactoring this page, but I am not able to come up with a polite, but precises keyword for addressing the issues mentioned at the beginning of the page. Namely that most/a lot of people in this field just don't know what they are doing. TheyAreClueless?, WhereIsTheMoney?, IdontWantToBeaProgrammer?, NotForTheLoveOfIt?, OnTheRoadToManagement? ProgrammingIsJustaTempJob? come to mind. Suggestions?

That sounds like a good idea: but I think the issues belong together (just somewhere else). Do you like MotivationsForBadDesign?, MotivationsForLackOfDesignEffort? or just plain WhyLackOfDesignEffort?. -- AlanGriffiths

Design is relatively easy. Good design is the hard part.