Good Design and Good Code
-
I'm on a project where I'm designing an extremely graphical and highly interactive application that interfaces with legacy applications. Right now I'm putting together a detailed design document for other developers to review. I got into a discussion with other developers where I asserted some statements that, on the surface, don't make too much sense, but I still think are true. Specifically, "Although we agree that good design might be necessary for good code to be produced, good code is necessary for good design to be produced as well". In other words, you can write up a design that looks good on paper and matches all the requirements, but until you've physically coded this design (or something very similar to this design), it's hard to say for sure that the design was really all that good. As smart as we might be, the cold reality is that no one is smart enough to make an initial design up front for a complex application until they've actually built something similar to verify that the design was, indeed, a good design. Just about any design can look good on paper to an entire review committee, but only designs that are based off past successful implementations of similar ideas can really be confidently considered "good". Has anyone else ever been forced to come to this conclusion before?
-
I'm on a project where I'm designing an extremely graphical and highly interactive application that interfaces with legacy applications. Right now I'm putting together a detailed design document for other developers to review. I got into a discussion with other developers where I asserted some statements that, on the surface, don't make too much sense, but I still think are true. Specifically, "Although we agree that good design might be necessary for good code to be produced, good code is necessary for good design to be produced as well". In other words, you can write up a design that looks good on paper and matches all the requirements, but until you've physically coded this design (or something very similar to this design), it's hard to say for sure that the design was really all that good. As smart as we might be, the cold reality is that no one is smart enough to make an initial design up front for a complex application until they've actually built something similar to verify that the design was, indeed, a good design. Just about any design can look good on paper to an entire review committee, but only designs that are based off past successful implementations of similar ideas can really be confidently considered "good". Has anyone else ever been forced to come to this conclusion before?
jesarg wrote:
Has anyone else ever been forced to come to this conclusion before?
Yup. Part of the biggest challenges when designing an application is being flexible and open to the fact that the code phase will result in your design being revisited and updated. Anybody who thinks that the design is finished before the code is doesn't really understand the dynamics of a software project. Effectively you can view this design phase as: Design what you want it to be Code it to be what it is Update the design to say what it is Or to put it another way - the simple fact of coding an application will throw up issues that the designer just didn't think of which will result in the design being updated. As a final thought - you've done your design. You've done your development and now you're ready to show it to the client (assuming you haven't developed it using RAD). They come in, love the product but want one or two "minor" changes - the design will change. So don't think you've finished with the design.
Deja View - the feeling that you've seen this post before.
-
I'm on a project where I'm designing an extremely graphical and highly interactive application that interfaces with legacy applications. Right now I'm putting together a detailed design document for other developers to review. I got into a discussion with other developers where I asserted some statements that, on the surface, don't make too much sense, but I still think are true. Specifically, "Although we agree that good design might be necessary for good code to be produced, good code is necessary for good design to be produced as well". In other words, you can write up a design that looks good on paper and matches all the requirements, but until you've physically coded this design (or something very similar to this design), it's hard to say for sure that the design was really all that good. As smart as we might be, the cold reality is that no one is smart enough to make an initial design up front for a complex application until they've actually built something similar to verify that the design was, indeed, a good design. Just about any design can look good on paper to an entire review committee, but only designs that are based off past successful implementations of similar ideas can really be confidently considered "good". Has anyone else ever been forced to come to this conclusion before?
jesarg wrote:
As smart as we might be, the cold reality is that no one is smart enough to make an initial design up front for a complex application until they've actually built something similar to verify that the design was, indeed, a good design. Just about any design can look good on paper to an entire review committee, but only designs that are based off past successful implementations of similar ideas can really be confidently considered "good". Has anyone else ever been forced to come to this conclusion before?
That's happened to me in nearly every project that I've worked on, and so far, the only consistent design principle that seems to make the most sense is to keep it simple. Good design comes from continuous refactoring, and by the end of a project, a lot of my designs tend to be emergent rather than something intentional. More often than not, I usually prototype my ideas using standard structured programming techniques (without using any OOP mechanics, such as inheritance). At first, the idea starts of as a very long and ugly static method in a single class, and then I usually use Fowler's classic Refactoring techniques to cut the size of the method down until it's broken down into static methods. At that point, it's still fairly useless since my code is still written to work with a particular prototype case, so the next thing I do is I refactor the static methods into interface dependencies and move the static implementations over to classes that serve as default implementations of those particular interfaces. The idea is to take the most straightforward approach to writing an application, and then refactor and generalize it so that you can extend it. TDD takes the same approach with its "test first" mantra, and this style of development has yet to fail me. (BTW if you want to look at some samples of my design work, click here.[^]) Now that I think about it, writing good code and having good design principles is like trying to sculpt a melting ice block in the middle of the desert. If you spend too much time thinking about what the design should look like, you'll end up with nothing but a puddle of water. If, on the other hand, you know exactly what you need to chip away in order for the ice sculpture to take shape, then a
-
I'm on a project where I'm designing an extremely graphical and highly interactive application that interfaces with legacy applications. Right now I'm putting together a detailed design document for other developers to review. I got into a discussion with other developers where I asserted some statements that, on the surface, don't make too much sense, but I still think are true. Specifically, "Although we agree that good design might be necessary for good code to be produced, good code is necessary for good design to be produced as well". In other words, you can write up a design that looks good on paper and matches all the requirements, but until you've physically coded this design (or something very similar to this design), it's hard to say for sure that the design was really all that good. As smart as we might be, the cold reality is that no one is smart enough to make an initial design up front for a complex application until they've actually built something similar to verify that the design was, indeed, a good design. Just about any design can look good on paper to an entire review committee, but only designs that are based off past successful implementations of similar ideas can really be confidently considered "good". Has anyone else ever been forced to come to this conclusion before?
jesarg wrote:
"Although we agree that good design might be necessary for good code to be produced, good code is necessary for good design to be produced as well".
"A chain is only as strong as its weakest link."