Design is not coding, coding is not design

Home

News: Design is not coding, coding is not design

  1. Design is not coding, coding is not design (73 messages)

    From Software Engineering: A Practitioner's Approach: "Even when detailed procedural designs are created from program components, the level of abstraction of the design model is higher than source code. The only design decisions made at the coding level address the small implementation details that enable the design to be coded." Do you agree?

    What are your thoughts about this design principle and how does it affect J2EE design, if at all?

    Is coding ever 'design' in the context of Software Engineering?

    I myself agree with this principle, but I'm interested in what TSS readers think.

    Threaded Messages (73)

  2. Considering most modern languages are a very high-level abstraction of the actual machine-code/instructions that are run from compiled code, one might argue that from that perspective modern programming is design at one level.

    Personally, I think a lot of people who are protective of their status and formal titles try ad absurdum to justify that "design" and "architecture" are separate areas of concern from programming.

    I myself subscribe to the idea that Fowler has proposed: that architecture/design are just words we use whenever we want to blow up the importance of specific, concious design decisions.

    But going as far as trying to draw a definite line in the sand between architecture/design and coding? An irrelevant academic excercise: you could argue that everything is design and nothing is design.
  3. A possible example of this?
  4. Design helps the programmer in not to loose the focus and deliver what is expected.Design helps the company or corporate who hires programers keep the knowledge that programmers create/created with help of designers & architects.Also it helps the same employers to know whether a group of people who "say" they can provide solutions are really capable of providing them.Designers are the persons who ensure that a problem is solved at least conceptually.Architects help in having the right solution.Why we need them?primarily because a solution to a problem should not be another problem.programmers,designers,analysts,Architects are all part of problem solving machine called software.Software that does not yield or be part of quanitifiable amount of revenue/profit is useless whatever technology is used.so design is definitely different than coding.
  5. Design == Coding?[ Go to top ]

    I am in the middle of having a new house built. I had to sign off on a rather large, impressive blueprint showing all my additions and customizations.

    Do Blueprints == Building the House?
  6. Analysis, Design, and Coding[ Go to top ]

    Design and Implementation (Coding) are two sides of the same coin. They both involve providing a solution - albeit at different levels of abstraction. Analysis is different. It involves the development of the problem statement. So in analysis, you determine the problem, and in design and implementation, you provide a solution.

    My design can be your implementation. I can create class B that is used to implement your class A. And my class B can be implemented in terms of someone else's class C.

    In addition, modern programming languages surely provide both design and implementation constructs. I would argue that creating abstract classes and interfaces is most certainly design work. Some may go even further and argue that any class creation in (language of choice) would be design - and it is not until you start creating for-loops and if statements (imperative programming), that you're actually doing implementation. Some may go further still and argue that the choice of a while..do versus a for... loop is a design decision. I don't think any of them would be wrong.

    High-level design and coding are both design, just at different levels of abstraction. A business model in UML can be handed to me, with all relevant business entities provided. And yet, in the implementation of that model, I may be creating interfaces and abstract classes that allow me to consolidate code and provide a more maintainable, cleaner solution. They are both design - again, just at different levels.
  7. Bad Title[ Go to top ]

    The author is arguing for a methodology that has long been proven ineffectual - hence the replacement of RUP by Agile and Extreme programming in many circles. The "big design up front" RUP model has never worked - it almost always ends in disaster.

    The practice of Agile, which promotes design=code, tries to do away with a lot of the extra roles that only get in the way. The developer is the coder, the designer, and the architect all at once. They see things more clearly, from the inside looking out - because we are dealing with a craft, much more than a system.

    Those "small details" of implementation usually contain about 90% of the thought that needs to go into the development. Dealing with the big-picture is simple. You dont need a giant diagram of stick figures to help you understand what the flow should be in a workflow. You don't need an extra person to make them - hire a "developer", not a coder, not an architect or designer. A developer will treat this as a craft, and you will end up with a quality product.
  8. The Architect don't code Anti-Pattern[ Go to top ]

    I'm agree with the first post that Programmers and Architect are too closer roles, I think an Architect like a programmer that has in mind the whole system and know what FrameWorks apply better for some issues...
    I mean after programming and taking decisions in the whole system you can be called an Architect...

    Like the title I believe in the Architect don't code Anti-Pattern...I think you must be a Programmer to become an Architect....
    today the languages are in a high level of abstraction so design and program are tasks related to the same person, I think is better to say a "Developer" as a role that encapsulate both: Programmer an Architect.

    Matias Basilico (Matutek)
    mbasilico@gmail.com
  9. ...I think you must be a Programmer to become an Architect....

    What about system administrators?
    Database analysts/administrators?
    Network Engineers?

    Systems (defined as the hardware, OS, basic services such as backup and recovery, system failover, etc), databases, and networks are all every bit as technically demanding as programming, just as essential in meeting the customer's needs, and very few programmers are really experts in these arenas, even if they think they are.

    So why can't an architect come from one of these disciplines?

    Shouldn't an architect understand user requirements and the business he/she is serving as well?

    Programmers saying architects should all be programmers is very ego centric.
  10. I have found the main difficultly is distinguishing if an individual is capable of being an architect. There are a lot of people with a few years of experience under their belt who tout themselves as being a software architect. Sadly to say most are not and are only inflating their title in order to get higher contract rates.

    So how does one determine if someone is capable of being and architect?

    Personally I am very cynical of people who call themselves Software Architects until I have the opportunity to work with them on a project. Safe to say this is not a very cost effective way of determining if a person makes a good software architect :-)
  11. What about system administrators?Database analysts/administrators?Network Engineers?Systems (defined as the hardware, OS, basic services such as backup and recovery, system failover, etc), databases, and networks are all every bit as technically demanding as programming, just as essential in meeting the customer's needs, and very few programmers are really experts in these arenas, even if they think they are.So why can't an architect come from one of these disciplines?Shouldn't an architect understand user requirements and the business he/she is serving as well?Programmers saying architects should all be programmers is very ego centric.

    You are right indeed. A Senior Developer that wants to be called Architect, apart from vast programming expertise must also possess decent knowledge on databases, networks and system administation tasks. In my view every developer must be able to set up Oracle database, or deploy his application on WebSphere cluster. You'll need dedicated DBA or system administrator only in very large projects or in very rigid organizations.
    The main point is that the experienced software developer might lack some specific query tuning skills or don't know how to create hardware partitions on high-end servers, or how to set up multi-home routing, but he must generally understand how all that stuff works. It's programming skills plus general system/networks/database skills that make up an architect. And I doubt that even highly skilled network engineer or DBA could ever fit architect's role.
  12. Compare Software with real world[ Go to top ]

    I guess most of the folks participated in this conversation are not undersatnding/understood the clear seperation between Architecture,Design and coding. Let me put this way.

    Architecting Home -------> Architecting App.s (Architect)
    (Architect)

    Design individual units
    of my home like
    Kitchen, Bedroom -------> Design Components (Designer)
    or how/where my
    home theatre system
    (Architect/
    KitchenDesigner/etc)

    Build individual units
    with the help of
    specialists like -------> Code comp.s (Programmer)
    plumber,carpenter
    electrician etc


    Now a home built with the help of plumber,carpenter,electrician without Architect and Architecture will not look as elegant as one done with good architecture and it will not be as durable as the one properly designed/architected.

    And in my comparison above Home Architect need not know plumbing or carpentry or need not be good electrician but the designer need to know the nitty gritty stuff in his specialized area. Similarly I guess software architect need not know or envision the each and every line of code while architecting. But Designer of individual components need to know/envision the implementation procedure and could able to give psuedo code samples if necessary.
  13. Compare Software with real world[ Go to top ]

    Also note that, we need to think from "whole to part" rather than "part to whole", while architecting/designing either software or building our new Home.
  14. What's an architect?[ Go to top ]

    isn't a sofware architect just someone who knows buzz words, but can't code worth a lick :)

    sorry, couldn't resist the joke.

    peter
  15. What's an architect?[ Go to top ]

    isn't a sofware architect just someone who knows buzz words, but can't code worth a lick :)sorry, couldn't resist the joke.peter

    well, I saw a project, where everything was messed in servlets, JDBC and LDAP connections were opened and closed on 200 different places, System.err.println was a logger implementation (1 gig of log files per day) and servlet 'service' method was 'synchronized'

    the reason of that was that an architecture and a design were not considered. maybe cost savings ...

    you can call this guy an architect, senior developer, guru or technical lead, but you definetly need her/him

    SW architect should have programming skills ...
  16. What's an architect?[ Go to top ]

    isn't a sofware architect just someone who knows buzz words, but can't code worth a lick :)sorry, couldn't resist the joke.peter
    well, I saw a project, where everything was messed in servlets, JDBC and LDAP connections were opened and closed on 200 different places, System.err.println was a logger implementation (1 gig of log files per day) and servlet 'service' method was 'synchronized'the reason of that was that an architecture and a design were not considered. maybe cost savings

    Call it what you want, but a good programmer (which you might call designer and/or architect) would not do the above. I consider architects on a level of Sr. Developer, who has the experience and knowledge enought to make concious development decisions.
  17. What's an architect?[ Go to top ]

    I totally agree. I do believe that a good software architect is first of all a very skilled and experienced programmer. It is very important that development experience should be in the area of applications architected. meaning that a skilled J2EE architect is first of all a skilled J2EE developer.
  18. What's an architect?[ Go to top ]

    In my opinion, an Architect is a really a really mature programmer. I have found myself in the company of this so called Architects who spoke big (excellent commo skills) but chocked on writing a Hello World program. Those who were excellent in PPT and VISIO, and were able to, even pass as Enterprise Architects.

    IMHO, an Architect should be able to roll up his sleeves and be able to demonstrate to a developer who is struggling to implement certain concept.

    Its like the script from "The Barbershop" that has been customized here to....

    "...See, in my day, an "Architect" was more than just somebody who sit around in a FUBU shirt with his drawers hanging all out. In my day, an "Architect" was a counselor. He was a design & coding expert. A style coach. Pimp. Just general all-around hustler. But the problem with y'all cats today, is that you got no skill. No sense of history. And then, with a straight face, got the nerve to want to be somebody. Want somebody to respect you. But it takes respect to get respect. Understand? See, I'm old. But, Lord willing, I'd be spared the sight of seeing everything that we worked for flushed down the drain by someone who don't know no better or care..."
  19. Code a lot, then start design[ Go to top ]

    I have posted whole a lot of archiect topic on my blog, Sunny Liu's blog. I called those non-hands-on archiect airbase software architect who knows theory, but do not even know how to write a line of good code. She/he only pollute the air nothing else.
  20. Poor coding vs. lack of design[ Go to top ]

    well, I saw a project, where everything was messed in servlets, JDBC and LDAP connections were opened and closed on 200 different places, System.err.println was a logger implementation (1 gig of log files per day) and servlet 'service' method was 'synchronized'the reason of that was that an architecture and a design were not considered. maybe cost savings ...you can call this guy an architect, senior developer, guru or technical lead, but you definetly need her/himSW architect should have programming skills ...

    What you saw was not lack of design but poor coding. Even projects that have massive, precise documentation and plans before coding can be implemented in a way you described.
  21. Poor coding vs. lack of design[ Go to top ]

    well, I saw a project, where everything was messed in servlets, JDBC and LDAP connections were opened and closed on 200 different places, System.err.println was a logger implementation (1 gig of log files per day) and servlet 'service' method was 'synchronized'the reason of that was that an architecture and a design were not considered. maybe cost savings ...you can call this guy an architect, senior developer, guru or technical lead, but you definetly need her/himSW architect should have programming skills ...
    What you saw was not lack of design but poor coding. Even projects that have massive, precise documentation and plans before coding can be implemented in a way you described.

    Nope, I have to disagree. Good architecture and design, which are also well documented, would avoid it.
  22. Poor coding vs. lack of design[ Go to top ]

    well, I saw a project, where everything was messed in servlets, JDBC and LDAP connections were opened and closed on 200 different places, System.err.println was a logger implementation (1 gig of log files per day) and servlet 'service' method was 'synchronized'the reason of that was that an architecture and a design were not considered. maybe cost savings ...you can call this guy an architect, senior developer, guru or technical lead, but you definetly need her/himSW architect should have programming skills ...
    What you saw was not lack of design but poor coding. Even projects that have massive, precise documentation and plans before coding can be implemented in a way you described.
    Nope, I have to disagree. Good architecture and design, which are also well documented, would avoid it.

    Really??? How the heck is your great architect going to stop a bad programmer from pooching the implementation?
  23. Poor coding vs. lack of design[ Go to top ]

    well, I saw a project, where everything was messed in servlets, JDBC and LDAP connections were opened and closed on 200 different places, System.err.println was a logger implementation (1 gig of log files per day) and servlet 'service' method was 'synchronized'the reason of that was that an architecture and a design were not considered. maybe cost savings ...you can call this guy an architect, senior developer, guru or technical lead, but you definetly need her/himSW architect should have programming skills ...
    What you saw was not lack of design but poor coding. Even projects that have massive, precise documentation and plans before coding can be implemented in a way you described.
    Nope, I have to disagree. Good architecture and design, which are also well documented, would avoid it.
    Really??? How the heck is your great architect going to stop a bad programmer from pooching the implementation?

    code review against the architecture, design and coding best practises requirments ... ?

    I am not a great architect, just an architect and I was SW developer for last 7 years. I do not see the code reviews as a problem ...
  24. What's an architect?[ Go to top ]

    <blockquotewell, I saw a project, where everything was messed in servlets, JDBC and LDAP connections were opened and closed on 200 different places, System.err.println was a logger implementation (1 gig of log files per day) and servlet 'service' method was 'synchronized'the reason of that was that an architecture and a design were not considered. maybe cost savings ...you can call this guy an architect, senior developer, guru or technical lead, but you definetly need her/himSW architect should have programming skills ...
    Wow, were we working on the same project this Summer? Or maybe there are too many projects like this out there.

    I think we need to see "architect" as a role not a job title. Someone needs to occasionally step into that role on any sizable project but to hire an architect is kind of foolish. The only other reason to sell yourself as an architect is if the hourly rate is better for the same work.
  25. What's an architect?[ Go to top ]

    isn't a sofware architect just someone who knows buzz words, but can't code worth a lick :)sorry, couldn't resist the joke.peter

    well, I saw a project, where everything was messed in servlets, JDBC and LDAP connections were opened and closed on 200 different places, System.err.println was a logger implementation (1 gig of log files per day) and servlet 'service' method was 'synchronized'the reason of that was that an architecture and a design were not considered. maybe cost savings ...you can call this guy an architect, senior developer, guru or technical lead, but you definetly need her/himSW architect should have programming skills ...

    Bad coding isn't something an architect can solve. I say this because even on projects with an architect that writes decent functional requirements, a bad programmer will royally screw things up. I've seen this first hand.

    If someone is a good programmer, I would argue they can step in and be an architect when needed. That doesn't mean they will be great for every single case. The key for me is to know what one's strengths and weaknesses. No single person is going to know everything well enough to be able to account for things that aren't technically feasible. I've seen plenty of cases where an "architect" asked for something that was not technically feasible.

    But it's not like this problem is specific to the architect role. Every level has these problems, so it's just a fact of life.

    peter
  26. What's an architect?[ Go to top ]

    isn't a sofware architect just someone who knows buzz words, but can't code worth a lick :)sorry, couldn't resist the joke.peter

    Actually, I refer to those people as talkitechts.
  27. What's an architect?[ Go to top ]

    +1

    -Pete
  28. Did I mention that UML is not just for Java programmers? What happens when Java goes away? How will we communicate the original architecture to next generation programmers?
    What about companies that create software for various environments? Shouldn't the design be similar?

    I agree 100%
  29. What about code-oriented design ?[ Go to top ]

    When a new feature has to be implemented, I often start from client code of the feature: how would I like the feature to be accessible ? This gives me the interface. Then I implement a small subset of the feature I want. I gradually add the feature I need, using the simplest approach to code first, then looking at the result and refactoring. Sometimes I'm stuck and I simply take another path, but most of the times you reach a solution that is both simple, elegant, easy to maintain and to extend.

    Too much upfront design brings unnecessary requirements and often is not able to identify the trickiest part of the design, those you catch when implementing.

    I've had the experience with a scheduler I recently implemented. One of our clients did a 50 pages analysis, imagined artificial requirements, took two months to implement it, and barely uses 5% of its functionalities. They have encountered many transaction-related problems. It took me 5 days to implement a simple yet functional and robust solution, that does its job and nothing else, simply using code-based approach and try/error for tricky parts.
  30. What about code-oriented design ?[ Go to top ]

    I absolutely agree with you! I have a CTO/architect title but I was a productive system programmer/hacker years so.

    I hate long design documents; I fall asleep after taking more than 15 minutes to read any document, while I have no problem doing coding for hours. (I passed my English 1A by reading only 5 inch worth of literature/Cliff Notes(R) out of 2 feet worth of assignments.)

    I do write some documents, mostly quite small. I used a lot of colorful diagrams in the documents but none is UML diagram.

    I think this UML is simply stupid! I would rather spend my times writing good API codes with readable class/method javadoc instead of these tedious, hard-to-arrange, hard-to-follow UML diagrams.

    I personal make sure it is a piece of cake to build and test the whole system. My new hires get their first assignments done in 3 days. I will make sure to find good refactoring tasks for them to learn the working of the whole system.

    I have done all these just to prove the architect I worked with before is wrong.

    And I attribute my distinct architecting style to the experiences from my years of being a hacker.
  31. UML is not bad, it's just misused.[ Go to top ]

    UML is not a programming tool, and far, far, far too many people like to think it is. Heck we have entire tools dedicated to the development of code using UML.

    UML is a useful tool if you know how to use it correctly. The first thing to do is throw away the IDEs and Tools and pull out a pen and some paper. Come up with a design, and if you think it's necessary, *then* formalize it in some tool. Be sure to keep it up-to-date if is a lasting design document.

    UML is an iconic way of abstracting and modeling systems. Sure, you can model systems with other diagrams, even in english, but the whole point of UML is to create a common language to abstract system designs.

    Abstraction is the key. If you're using a tool that requires you to define every method and field in a class just to do a simple diagram, then reconsider your process and get another tool. UML diagrams should show only that which is necessary to get the point across (just like any good technical documentation.)

    UML is a tool to enable communication. It is nothing more, nothing less. It is up to you to properly decompose the problem and abstract your system design.

    If you can't communicate clearly and concisely, then you are in for a world of hurt. Regardless of the tools you use.
  32. UML is an iconic way of abstracting and modeling systems. Sure, you can model systems with other diagrams, even in english, but the whole point of UML is to create a common language to abstract system designs.
    I think UML has failed as a "common language" and become a programming tool for this reason. Other diagrams and english can abstract system designs better, UML has too many details and complexity (it is more complex than code)
  33. Again, you don't have to use the all of features of UML in every diagram! You shouldn't be afraid to use just the UML you need. And don't be afraid to mix and match diagrams.

    Far too many people try to use overly designed tools to draw their diagrams. Forget about code generation! Draw pictures to represent your system... Abstract to show only the detail necessary to get an *idea* of how the thing is supposed to work.

    What most people are missing is that whole *abstraction* thing. You should not use the full complexity of UML to diagram your systems. The "complexity" is there to provide a standard way of rendering bits and pieces of diagrams.
  34. Design is ... and code is ..[ Go to top ]

    Architecture: (ärk-tkchr)
       A diagram using colorful blocks used to cloud the judgement of the CIO and trick the CFO into signing away monetary assets to acquire potential software.

    Design: (d-zn)
       The artifact that gives you delusions that your software will work as envisioned.

    Code: (kode)
       The reality that dispels the delusion with a long list of "technical assistance requests" or bugs.
  35. Design is not coding, coding is not design[ Go to top ]

    I think the book should be renamed:
    Software Engineering: A Non-Practitioner's Approach
  36. Design is not coding, coding is not design[ Go to top ]

    Software Engineering: A Non-Practitioner's Approach

    Brilliant, if biting, wit. I hope you don't mind if I steal that line.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Coherent Caching
  37. Code as Design a No No!![ Go to top ]

    Come on guys,
    How do we ensure that the design is correct?

    That the User Acceptance tests and Quality Assurance Tests are based not only on high level requirements but on a more strong design principle.

    This design should be abstract from source code. We should use: use cases, activity diagrams and of course model our design using UML for the OO paradigm or which ever one.

    This will allow our Snr. developer, Architects and most importantly project managers to understand the design and allow for a team unified process.

    We need to ensure that we build software that conforms to a design, not to a implementation(source code).If we don't God help us.
  38. Code-Design: Conjoined Twins[ Go to top ]

    I find software design is critical when large teams are collaborating. Design artifacts (UML) are great for peer reviews. It is much quicker, less painful and cheaper to fix any issues during initial designs, through design reviews, than later in source code, when source code has issues.

    Well, you could always code first and then refactor - "refactor existing code to improve design" (Fowler). That won't work in most cases. Selling a refactoring story to business to finance is an art that few of us posses. So I say fail fast and fail quick - during design.

    All in all - I think design and code should be joint at the hip. Rest can be left to the non-practioning software architects.
  39. Code as Design a No No!![ Go to top ]

    Come on guys,How do we ensure that the design is correct?That the User Acceptance tests and Quality Assurance Tests are based not only on high level requirements but on a more strong design principle.This design should be abstract from source code. We should use: use cases, activity diagrams and of course model our design using UML for the OO paradigm or which ever one. This will allow our Snr. developer, Architects and most importantly project managers to understand the design and allow for a team unified process.We need to ensure that we build software that conforms to a design, not to a implementation(source code).If we don't God help us.
    To me, this is not design, but requirements analysis. Those are indeed sometimes needed - particularly if the business to model is complex and rigid - but they give you a detailed view of the problem, not of the design (which is a high level solution of the problem)
  40. Code is Design[ Go to top ]

    Come on guys,How do we ensure that the design is correct?
    [I am taking on a definition of Design as "creating a natural-language or graphical representation of a technical architecture"] By coding it. Which in most cases proves that it isn't correct, because no one is able to capture even the relevant aspects of a system up front.
    We need to ensure that we build software that conforms to a design, not to a implementation(source code).
    Wrong. We need to ensure that we build software that conforms to a defined set of requirements, at a user/business level (getting those is hard enough). That, and only that is the measuring stick.

    Christian
  41. Design a little, code a little...[ Go to top ]

    How do we ensure that the design is correct?

    The design is never 100% correct, unless it's something very simple.

    In my experience, the following approach works the best: "design a little, code a little, test a little, repeat."

    --
    Igor Zavialov
    Factoreal Financial Data and Technical Analysis solutions.
  42. Design is different thatn Code[ Go to top ]

    I think during desinging one should also write some piece of code to verify small technincal details as well as clarify lots of issues that sould be left out if only designing is to be considered.
  43. It is still important to define what is meant by "little" here. I have seen many project loosing the consistancy on the design by defining this unit of measure to be 'too little'. Always we need to define several levels of abstractions in our design which would evolve as the time passes.

    For an example before starting coding any project need to have atleast a abstract set of boxes representing overall architecture of the system. Also in the other end we need to define the logic flow between classes that will make the UI of the system (e.g. how to layout MVC). Specially this level of details are required when several developers are working on a similar task and some of them are not very expierienced. I'm not refering to detailed UML diagrams here but a 5 mins team meeting will also work.

    It is not just a matter of getting the design better but helps to improove the developers knowledge on good practices. Being an architect ur responsibility will not be limited to getting a good design out but u r responsible of improoving the developer knowledge also..

    Hasith Yaggahavita
  44. Design is not coding, coding is not design[ Go to top ]

    I think the book should be renamed:Software Engineering: A Non-Practitioner's Approach

    How this text stack up against the other Software Engineering textbook by Ian Sommerville?

    I prefer to use Applying UML and Patterns by Craig Larman for my Software Engineering courses.
  45. IT doesn't exist without the business/customer/market needing something from it. Most of the hard product that comes out is code-based (as a great project manager I worked for once said "we can talk and talk and draw nice pictures but it's only people at keyboards typing that make us look like we delivered"). But, there are obviously myriad layers of abstraction between the idea and the cutting of code.

    The original question "The only design decisions made at the coding level address the small implementation details that enable the design to be coded. Do you agree?" Merely examines the relationship between two of the lower layers. These are layers that should be addressed by the same person and I don't agree that they represent a classic separation of concerns to the extent that they leave coding to be only about 'small implementation details'.

    But I can't leave some of the architect-bashing above. Whether the title is right I guess is a subjective/emotional question - maybe architect is too fancy a term. But there does have to be a role that looks at big picture non-functional requirements (transactional integrity, scalability, etc) inter-project concerns (maintenance, operational concerns) strategy (tool choice, use of standards/best-practice), and so on. Maybe it's fair to say they don't always do a good job, and maybe having a pop at the fact that they do a lot of drawings and are never around to take the flak when it goes pear-shaped is justified, but good ones are invaluable. Whatever schmancy/cheesey job title they have.
  46. The only way to enforce a design is to test it. This includes functional and non-functional aspects of the design. UAT, unit, performance, and profiling.

    I think Fowler said running a compiler was the construction phase of a project and everything else related to laying out the code was design.

    J2EE, patterns, frameworks, best practices, and most importantly, tools (wizards, code generators, and aspects) allow coders to be designers. Why code when you can configure.
  47. It is my firm belief that analysis and design skills are critical components at every level of the software process.

    Sure, source code (with decent comments!) can be considered a design document, but you still have to put thought into it. This thought is design. The more skilled you are at design (such as basic GRASP principles) the better your code will be.

    You can't code software unless you have a design. Even if you just jump into code, you are creating a design, and if you haven't thought it through, then you are asking for trouble. Sure, you can refactor, by why refactor if you can consider design issues up front (whenever possible?)

    Refactoring should be reserved for design issues you were not able to conceive of (or were too expensive to implement) in a previous iteration.

    I believe in agile methods. But agile methods do not dictate that design is dead. You can't just start coding and hope that you get a good product. You have to spend some time in each iteration thinking of how to attack the problem... and this *is* analysis and design. In agile methods, design has become a fluid process, and not something that has to be done all at once, up front (as in traditional waterfall-style methods.)

    To be successful in agile development, you are going to have to start with a high level design and refine it iteratively. This is the most significant change introduced by agile development methodologies -- recognize and embrace change and be willing to reconceptualize the design through the phases of your project... this does not mean that you should ignore design completely.

    I've found that the Pressman book (at least the 5th edition I have) mentioned in the orignal post contains a lot of notions that follow the traditional waterfall style methods, although the text does reference RAD, spiral and incremental models as well. In truth, I think the answer lies somewhere in the middle of the typical rigid methods and the newer, more agile methods.

    I highly recommend the book _Applying UML and Patterns_ by Craig Larman for further research into agile methods and design principles.
  48. It is important to understand the current state of the developemnt lifecycle to decide on the right amount of design details and UML diagrams to be used.
    Detail designs and UML artifacts are more usefull at some stages then other.

    Architects should develop this understanding of the iterative stage of the overall design and development process.
    At some stage when the designed component span multiple team/groups it is more usefull to lay down the higher level design details(or more details with group brainstorming) with appropriate UML diagrams for shared understanding of the development requirements. At some other stage(writing an algorithm) it is good to leave process details to the program developers.
  49. It is important to understand the current state of the developemnt lifecycle to decide on the right amount of design details and UML diagrams to be used.
    Detail designs and UML artifacts are more usefull at some stages then other.

    Architects should develop this understanding of the iterative stage of the overall design and development process.
    At some stage when the designed component span multiple team/groups it is more usefull to lay down the higher level design details(or more details with group brainstorming) with appropriate UML diagrams for shared understanding of the development requirements. At some other stage(writing an algorithm) it is good to leave process details to the program developers.
  50. I disagree with your opinion that sequence diagrams are more related to code than to design.
    I could agree with very detailled class diagrams.
    But in a real word, you should enforce yourself to say what you to want or code before coding it, then code it, and maybe change your first objectif to something more realistic due to constraints.
    So to my point of view, using sequence diagrams is much more than useful, it is necessary, in the design process. But you don't necessary need to have exactly all methods, all details, and of course not the name of the class at the design level.

    Doing things by iterations makes it possible to communicate, which is the main interest of designing, to different people.
    To communicate between coders, very detailled UML diagramms are simply the code or examples of codes.
    To communicate between architects, detailled UML diagramms makes it possible to know in advance, without looking at the code, the cost of a new feature, the cost of maintenance, what is possible in the feature, and what is not.
    To communicate between architects and people involved in functional requirements, high level UML diagramms like sequence diagrams and use cases are good. Java interfaces are simply a specific kind of UML class diagramm.
    That is why it is better if analysis requirement is already done in UML and not by some ambiguous sentences that let the choice to voluntarly misunderstand what was specified.

    What is incredible in most commentaries here is that people either code or design, but , in real world you should both design, then code. The way to do it is not : I design then I code, but I design, I communicate, I change my design by taking into account peer reviews, I code, I change my design because coding helps me to see some new constraints, or in the contrary I noticed that my design was too complex to code for my real need, I then make my unit test plan, code, and finally update my final design.
    My first turn of design should in principle be quite unchanged between the first iteration and my last iteration as it only models high level principles.
    In the contrary, very detailled design is very likely to change each time the code changes, so maintaining it could be unuseful. Depends on the tools you chose (like MDA tools).
  51. Design IS coding, coding IS design[ Go to top ]

    In truth, I think the answer lies somewhere in the middle of the typical rigid methods and the newer, more agile methods.

    I consider the design to be embeded within the user stories of a project. Given a certain set of user stories for a given iteration then I will design at a high level (meaning using the most common design patterns) but I will not go down to defining interfaces or method call chains. Instead, with the over all picture I proceed to code by using Test Driven Development. At the point of using TDD I have noticed that the tests change the code implemetation and thus the design will mature and evolve as I write tests and code. I think this is a point we miss often, in that the design of the project will change (sometimes drastically) as more of user stories are implemented. Yet, since the user stories will not change that drastically... this is the level of abstraction that contains the true end design. It is a matter of coaxing it. As long as the acceptance tests are valid and all unit test run then we could argue that the test actually are the interface between the user stories and the true design expressed in the code.

    As far as documentation, I do not do much. I do keep a live document of the current design at the end of each iteration but this is mostly to capture the progress. At the end the "design document" could be used by someone who is examing the code and the tests in order to understand the project. Thus the "design document" is in a way incomplete... it gives you the overall picture but does not give you the nitty gritty found in JavaDocs, code and unit tests.

    In conclusion:

    Design IS coding, coding IS design
  52. Design is not coding, coding is not design[ Go to top ]

    In one of the large scale project that I was involved. My customer kept asking for more documentation and down to a point that they wanted detailed description for methods (something like step by step descriptions). The customer technical guru insisted class diagram (in UML) to be provided for thousands of classes even though the inheritance relationship can be generated via JavaDoc. His reason was for maintainability! I could not help but wonder how the set of documentation can be maintained in the future. In a way, if too detailed documentation is provided, I believe the developer who is going to maintain the application would rather read the source codes!
  53. design happens while coding[ Go to top ]

    Anyone who thinks it is possible to design 100% of an innovative software product, before writing code, is ... wrong.

    I had a boss who taught me the "first waffle priciple". That is, expect the implementation of your first design to be like the first waffle you cook. It lays down the grease so the next waffle comes out better.

    I have always found that the coding process reveals actual, not accidental, complexity that was not understood at the time the model was created on paper. If the paper-design is lossly coupled and flexible, you can do some on-the-fly designing. The fewer participants the better - ideally one. And this is why most successful projects actually do begin with a single "hero coder" who brings the project from inception to first waffle. At that point, the tinkerers can get involved and produce subsequent versions.

    -geoff
  54. lession from architecture[ Go to top ]

    I have several "architect" friends. One of them told me that Sears Tower comprises of nine square tubes. The "nine square tubes" is the design behind Sears Tower.

    To me, building software is very much like building houses. Behind software usually has a simple design concept and developers write code around it. Without design and overseeing, I don’t believe 10 great developers can forge great software like I don’t believe Sears Tower would ever get built with just thousands of constructors.

    I agree with one of the post that UML is just misused. Human doesn’t remember complex things. So we simplify or abstract concepts. Human are also graphics oriented. You probably don’t remember Rutherford’s atomic theory by "… suggested that the atom consisted of a small, dense core of positively charged particles in the center (or nucleus) of the atom, surrounded by a swirling ring of electrons…" but you do remember the simplified model like the one on this web site http://www.classzone.com/books/earth_science/terc/content/investigations/es0501/es0501page03.cfm UML is a great tool to communicate, polish and document design.

    One difference I see between software architect and "architect" architect is that software architect should have strong coding skills. Sometimes, they should roll up their sleeves, too.
  55. Spaghetti-code[ Go to top ]

    As long as you don't want to end up with 1Mb of unmanageable spaghetti-code, some design is needed before you ever start thinking what language to use in your project.

    Hey... I told you "some design", not two years of discussions and 3000 pages of UML diagrams. I agree with those who say thay UML is abused, thus leading to the convinction that it only creates confusion.

    I think a lot of people here do not see the real nature of the problem: if you're doing just a trivial internet site with a relational database behind, there's no need to design: one person is just enough to to the job. Me too (a fanatic of design) do little (to even no) design at all in such scenarios.

    But consider a big project where 5-10-15 people are working together on different aspects of the project...
  56. Recommended reading[ Go to top ]

    I strongly recommend reading "What is software design?" by Jack Reeves. The first article is from 1992 and it still holds...

    href="http://www.developerdotstar.com/mag/articles/reeves_design_main.html

    /Tommy
    VisionProject
    Issue tracking and project management made easy
  57. This is my personal point of view but I think many of you will agree with me.
    Not every thing called "design" is real design. I think that "telling what data the user wants to see and what functionalities wants to have" or "telling what the machine must do" is real design. How you want to achieve these requirements is still design. But telling how your code must be connected or how it must work is not design!
    In an UML perspective (and still in my perspective), use-cases and activity diagrams are design tools, while class diagrams, sequence diagrams, collaboration diagrams are simply code in disguise! They are useful (still very useful!) only for documentation.
    In my experience, I make some use cases and activity diagrams (or equivalent diagrams with different methodologies), then I start coding and, after all, make some class-sequence-collaboration diagram to show some examples.
  58. If we are talking about application development then there is nothing to "design", just take a framework and extend it with domain specific stuff, as less "architect" fights with framework (redesigns and misuses) as better for project. I think requirements and domain specific documentation is the most important thing in application development project, but this is a business analyst job.
  59. while class diagrams, sequence diagrams, collaboration diagrams are simply code in disguise! They are useful (still very useful!) only for documentation.

    Yes, class diagrams (and the others, but I'm going to focus on classes) can be "almost code," but they don't need to be.

    There's no reason why classes can't modeled on a conceptual level that's far higher than typical code. In fact, I spent much of this afternoon using class diagrams (hand drawn on a whiteboard with simplified notation) as part of requirements elicitation.

    I say "typical" code because it is possible to bring code much closer to requirements than developers usually bother to do.

    For example, a part number may have several constraints associated with it, such as min/max length, be all upper case, have a set of illegal characters, etc. However, in the end it's just a string. A programmer could create a part number class that embeds these rules, but chances are the programmer with model/code a part number as a string and stick the rules in the "set" method of the class that contains the part number.
  60. The house of bricks[ Go to top ]

    I think it is not productive to apply a single notion of what design should be to each and every part of a system. The level of upfront thinking and the formality of expression must depend on the cost of changing the particular part of the system later on.

    Someone on the team has to decide what the right amount of formal design, the right amount of separation between coding and design, the right amount of quality assurance, etc, should be for different kinds of interfaces.

    An interface of a module that is used by thousands of clients, that I don't have organisational control over, has to be designed differently than an interface between two pieces of my own code. Interfaces between independently versioned modules have particular requirements that are not the same as those for modules that are kept in sync at all times and are written in the same language.

    Some interfaces have only one implementation, others are meant to be implemented by different people, at differnt times but should be semantically equivalent.

    Another important question is the different roles you have on a team and which formal or not so formal languages each person understands.

    Sometimes there are contractual obligations and cost estimates that require a certain amount of upfront design before coding even starts.

    Some systems are done on the bases of a well known business problem. Others have to evolve with the development of the business requirements themselves.

    These are all very different situations and someone has to think about all of that. Is this person a coder? Is it an architect? A product manager? I don't think the title matters as long as it's someone who is aware of the very different dynamics, costs and organisational implications of various kinds of interfaces and design decisions.
  61. Design vs Architecture[ Go to top ]

    People here seem to be equating design with architecture.

    Design is what you do (explicitly or implicitly) before you start coding.

    Architecture is what you do (explicitly or implicitly) before you start designing.

    Architecture incorporates all of the non-functional constraints that will apply to your solution (runtime software products) and development process (designing and codeing). This includes analyzing the problem domain and coming up with the general contours of the solution domain, including:
    - What kind of production environment will the solution live in? What types of machines? How much CPU? How much memory? How much disk capacity? What kind of network?
    - What are the major components of the solution? How are they related? How will they communicate?
    - What kind of System Testing environment do you need to support such a production environment?
    - What type of development environment is needed to support this solution? What operating systems? What frameworks? What scripting languages? What design tools? What development languages? What development tools? What build tools? What third party libraries? What are the standard operating procedures for this development environment? What unit testing policies and standards? Nightly builds? Continuous integration? Are there policies regarding circular dependencies? At the code level? At the component level? What coding standards? What is the release process? When do we branch? How is branch development merged back into the trunk? Under what circumstance should we use parallel development? Etc, etc, etc.

    Maybe some of these activities are 'Architect' activities and some are 'Senior Developer' activities, but none of these are Design in the sense of, I'm getting ready to code. Oh yeah, how am I doing this again? How is this going to work?

    BTW, I agree with the sentiment that design is basically vaporware until it is coded and tested. And if the designer is long gone when the testing is done, how are they going to learn from their mistakes and become a better designer? I am very skeptical of "designers" who can't follow through to the final product with coding and testing.

    Ok, I feel better now. If you'll excuse me, now I'll go RTFA.
  62. Design vs Architecture[ Go to top ]

    I get the feeling from most programmers despise working with managment/analysts who are not strong technically. Also from previous experience if a company hires an architect, they usually do not participate in any coding activities because it is "beneath" them. I think the issues that are raised here are related to dealing with people and the defenition of roles.
    People here seem to be equating design with architecture.
    Design is what you do (explicitly or implicitly) before you start coding.
    Architecture is what you do (explicitly or implicitly) before you start designing.
    Maybe some of these activities are 'Architect' activities and some are 'Senior Developer' activities, but none of these are Design in the sense of, I'm getting ready to code. Oh yeah, how am I doing this again? How is this going to work?
    Well said! The design phase is when the architects get together with designers and create a reference implementation or prototype. I am not going to get into the benefits of this because everyone already knows what they are, but this of course raises yet another issue. Business sees the prototype and thinks it is production quality so no one even bothers.

    Why we need pictures (UML)...
    Architects need to be savy people, often time as persuasive as car salesmen, who can communicate the amount of work it is going to take to create a functional software application that meets the business needs! WE have to understand that the CXO's do not understand what we do, every other industry has something they can show for the amount of hours they spend building something. Cars have visible parts, buildings & homes are huge structures which are visible, etc... When the CXO opens up their browser or double clicks the icon on the desktop, do they see Factories, Command objects, Controllers, JMS Subsribers, ResultSets, Stored Procedures? NOPE they only understand the view layer and that is all they care about (occassionally VPN or https protocol to "protect" their information).
    If we can show them "pictures" then maybe they will understand why it will take more than a week to retrieve inventory data from a mainframe and display it on their PDA, even though we have 5 people and three teams working on it.

    Did I mention that UML is not just for Java programmers? What happens when Java goes away? How will we communicate the original architecture to next generation programmers?
    What about companies that create software for various environments? Shouldn't the design be similar?
  63. Design vs Architecture[ Go to top ]

    People here seem to be equating design with architecture.Design is what you do (explicitly or implicitly) before you start coding.Architecture is what you do (explicitly or implicitly) before you start designing.

    I concur with all the points, and here is my view:

    When one just starts thinking how to solve a given problem (as defined by requirements) in my view he/she starts doing design. Coding without design for me is "coding without a thought" - it is like being a monkey trying to type Shakespeare by mere chance... Now, you might not put the design on paper but you do think (hopefully). When more people are involved or join in the further project stages, communication starts failing thus design requires documenting.

    Now thinking is a "free" process... In my experience if a project does have certain goals and one wants to achieve them "freedom" very often is an obstacle.

    A team of developers left to themselves very quickly tends to detoriate into "a bunch of developers" and from there there is just one step to "a crowd". And some of the things crowds are famous for is "crowd instinct", usually describing illogical behavior and that exact "freedom" as in "I am in the crowd by actually I am on my own free to go where I want"

    Now Architecture for me is a boundary for design, boundary for thought, boundary for excess of freedom in a project. For me it is essential as it turns infinite universe of possible directions a team may take into a finite scope, which is possible to access, estimate, and yes - "sell" to business.

    Another way of looking at it:

    If requirements answer (hopefully) the question: what?
    Code answers the question: how?
    Design answers the questions: with what? in what way?
    Architecture answers the question: what if?

    And I really prefer if it answers this question with specific statement as in "Scalability - put more machines in the cluster" or specific ban (veto) as in "SFSB - forbidden, for this and that reason".
  64. Design is at differnet levels[ Go to top ]

    I am a big fan of the sofwtare architecture people at CMU (Shaw, Garlan, Bass etc). Software architecture should be seen as design at a very high level of abstration. It is based on an individual or team's perceived solution to meeting the key drivers for the software (primarily non-functional requirements). However, based on my experience of programming and low level design it is also true that the "devil is in the detail" when it comes to the finer points of validating key design decisions. Software architects who make crucial design-technology decisions often get them wrong. Design at both the architecture level and low implementation design HAS to be iterative and "agile". At the same time leaving developers to design and document a software system is unreliable in large projects (where turnover of key developers may occur).

    In my opinion software architecture is deliberate design at high level of abstraction driven by the non-funcs but at the same time I have realised that the best software architects on projects tend to be senior developers with good habits of useful documentation in UML and follow a good agile process. In short the best software architects tend to be senior developers fluent in the implementation technologies, but who also possess skills in descriptive languages (UML) and software process.

    Size, skill and length of projects tends to determine the best mix of these.
  65. In my opinion, it's up to the designer to balance the distance from the design to the coding, leaving just one question:
    "Why should we design all aspects of the program using a non-programming language (ex: UML) if it's easier to just write it in Java?"
    I think that a design should guide the coding, but not replace it, because what's the benefit of designing all details of the software instead of coding!?
    Another point is that the expression power (for program specification) of modeling languages used for designing isn't as powerful as a programming language. It's exactly one of the issues that UML 2.0 tries to address, and just take a look in it's specification and see how complex it's becoming.
  66. I think the argument over what's requirements, what's architecture, and what's design is rather silly.

    IMHO, engineering is the process of solving a problem through the application of scientific principles. It is typically accomplished by breaking the problem into multiple smaller problems via abstraction until the problems can be solved by a known solution or are tractable to the engineering team.

    From this definition, it should be obvious that the larger your problem is, the more abstraction you're going to need.

    Unfortunately, people tend to make several false assumptions:
    1. Abstraction must be hierarchical or layered in nature.
    2. There is a pre-defined finite number of levels of abstraction that can be used to solve any problem.
    3. Artifacts (documents, models, code, etc) with certain labels (driven by the finite levels of abstraction above) are equivalent to good abstraction.

    Instead, the engineering team should make sure that there is a clean transition from the problem defitinion (which is the root abstraction) into its immediate abstracted elements and through all the abstractions needed to solve the problem.

    Artifacts are used to communicate these abstractions among members of the engineering team, with the team's customers, and with any black-box abstractions (a compiler, a software library, etc) being used.

    So, if the problem is "output 'Hello, world!' to the console," then code is probably all you need. If the problem is implementing an air traffic control system then you need a whole lot more.
  67. design is hard to control[ Go to top ]

    There is such a thing as too much design, documentation and UML. Ever seen huge UML diagram and Rational Rose? You spend most of the time scrolling and finding relationships between classes. This is because most developers think in terms of implementation when they are really capturing the design.

    When possible, use frameworks (Struts, home grown etc.) which minimize the amount of "design" (diagrams etc.) to be documented (because hopefully everyone knows how the frameworks work). Later, during development, lead developer or equivalent could draw the UMLs, from which other developers could generate code. This way most of the developers only have to know about the framework and implementation details.

    Chintan Rajyaguru
    http://chintanrajyaguru.com/blog
  68. Those "small details" of implementation usually contain about 90% of the thought that needs to go into the development.

    I've never seen that happen, but I have seen close to the reverse - where the small details use about 10% of the development effort.
    The "big design up front" RUP model has never worked - it almost always ends in disaster.

    Without design/architecture/many levels of abstraction it is impossible to divide a large scale system in parts. There's no pre-division of the system into part (and the parts into parts and so on) there's no way to effectively split the labor of creating the system amoung tens, much less hundreds, of developers. If you can't divide the labor among many, many people, you can never produce the millions of LOCs necessary to complete the system.
    You dont need a giant diagram of stick figures to help you understand what the flow should be in a workflow.

    Maybe not, but without that diagram how are you going to verify with your customer that it is correct? How are multiple developers going to now how their parts of the flow fit with other parts? How are new developers ever going to come up to speed? New users? What happens when the flow is too complex to hold in your head?

    The purpose of code is to enable the programmer to talk to the computer. The purpose of documents/models/diagrams/etc is for people to communicate with other people.
  69. As someone who was (and is still) a hacker and becomes an architect, I would agree with you that both the "design" and the coding ae both needed.

    And the two cannot really be separated. The problem is that there are two camps of people: the "architect" people insist that if they come up with a "good" design and then good software will be written; the "hackers" will trash that notion and believe they can create good programs without any design. Neither is true. We must take the middle way.

    I would also agree with Reeves' article from my experiences as both kinds. (And I just read this article yesterday.) A lot of detail designs cannot go into documents. The Design Document should focus on a very high level (above class diagrams.)

    What's wrong with UML is that it is trying to imitate the data declaration part of any languages but really what we need are standard block-shapes found in PowerPoint. (I do like and use the standard class extension and association arrows in UML.)

    What I found is that many software architects do not do a good job of designing the high-level structure yet trying to put excessive details in the design documents; and they can't really handle those details well either without testing in real working codes. They must design main class hierarchy but they should write right in the codes with readable/meaningfule documentation comments.

    On the question of how to show the design to customers, the answer is indeed diagrams. However, customers will never understand UML! (Especially the ones with more than a few classes in it.) What you need is PowerPoint! That's only way to get your customers understand/pay for your design. (OK, to be more formal or if live presentation is not possible, you can throw in some Word documents but the diagrams and outline are from your PPT slides. You just need to add more details.)
  70. Design vs Coding[ Go to top ]

    Howdy All,

    Design and coding are clearly two different things: design is finding and specifying solutions to problems, and coding is implementing those solutions. Design can happen at many different levels (from high to low) - systems design, application design, class design.

    Now, some people do design whilst they are coding (and primarily use the code to capture their design), and some people prefer to do most of the design before they code (and document that design separately). And there are, of course, many options in between these extremes.

    Designing and coding are distinct tasks, just as designing a building and pouring the concrete or laying the bricks are. Even if you don't think you do design - you just code - you are really doing design in your head as you code (and good luck with that for complex designs and when working in groups).

    Personally, I don't think code is the best way to think about a design or to represent a design (for documentation or other purposes). But then, of course, a design without an implementation is usually unproven. That is why most people embrace an iterative development model these days.

    I'm a practioner and an educator and in my education role I teach design (without coding). By the time my students are finished the course they see that there really is an activity called design that can be separate from coding, and it is a most important, most difficult and most interesting task.

    Cheers,
    Ashley.

    --
    Ashley Aitken
    Perth, Western Australia
    mrhatken at mac dot com
  71. I went back and read the original seminal article (argument?) on the topic:

    http://www.developerdotstar.com/mag/articles/PDF/DevDotStar_Reeves_CodeAsDesign.pdf

    It's well written, logical and persuasive. As the author says, it's not provable and it's open to debate, but it's worth a read.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Coherent Caching
  72. Design is not coding, coding is not design[ Go to top ]

    From Software Engineering: A Practitioner's Approach: "Even when detailed procedural designs are created from program components, the level of abstraction of the design model is higher than source code. The only design decisions made at the coding level address the small implementation details that enable the design to be coded." Do you agree?What are your thoughts about this design principle and how does it affect J2EE design, if at all?Is coding ever 'design' in the context of Software Engineering?I myself agree with this principle, but I'm interested in what TSS readers think.

    Let us consider the reason we have these concepts in the first place.Design at the highest level represents a solution within the premises of the problem domain itself,nothing of software engineering may be required for the same.( unless ofcourse the domain itself is software engineering).From here we try to see how best this solution may be implemented , using our experience of behaviour of software.An implementation is the goal.If by "code" you mean the deliverable ,deployable software,which only the machine understands:there is no coding at all, only steps to code generation.Keep in mind that code may be generated immediately, even from a UML diagram,forcing us to change the definition of code to the UML source in this case.

    As we see above code and design are conceptual tools.The mere concept of a possible solution is "design"(design itself may need finer design) and anything that can get this solution working and running on a virtual machine at any level is "code".

    How much of design is needed to see through a clear deployable piece of software varies .But once seen, the rest is what I call "code".
  73. We also need to highlight the role of 'design patterns' in
    architecting->designing->implementing a solution. They can really help in bridging the gap between the solution design and implementation coding.
    They can also help in developing a common and shared understanding of the SUD(system under design) goals, significantly reducing the design details and documentation.

    Teams should identify/document these invented/discovered design patterns used in their projects to capture and share the project learning.

    Project knowledge captured in these design patterns can be shared across different software development projects and teams.
  74. Does everything need to be REdesigned?[ Go to top ]

    I like Martin Fowler's book "Analysis Patterns".
    Why?

    Because I often wonder why I'm creating designs for inventory, accounting, sales, customer data, etc..

    Is it that nobody else in the world ever wrote a computer program to solve this?

    Why aren't there more books that tell you how to IMPLEMENT such software (where the analysis is spelled out and a design is proposed)? Why aren't there class libraries already made that I can extend to my particular problem? (like one based on "Analysis Patterns")

    Why do we often reanalyze problems that have been solved a million times?

    If you're going to build a bridge you usually KNOW a few ways to do it before you actually try to adapt a design to a construction (there are exceptions I'm sure). Why do software developers need to think of problems from scratch each time?

    Data structures, frameworks, O-R tools are nice.. but how about business libraries?