SitePoint Sponsor

User Tag List

Page 2 of 4 FirstFirst 1234 LastLast
Results 26 to 50 of 86

Thread: UML, PhP 5, MVC

  1. #26
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by jayboots
    Maybe it is just me but something I noticed about sitepoint is that if something isn't used, appreciated or understood by a vocal minority, it gets shouted down and dismissed very quickly and without any thoughtful reflection.
    Then you haven't been paying attention. This forum tends very much to the opposite, that's one of the reasons I like it. Lot's of new ideas, even mad ideas, have had a chance to take flight here.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  2. #27
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Galo
    BELIEVE ME, plan or fail.... i've been there to, many re-writes and eventualy end up with nothing...
    We don't plan too far ahead, we do some rewriting (on the small scale) and we are doing fine. Very successfully in fact, so I DON'T BELIEVE YOU .

    Plan ahead (or phased development or "waterfall") suits a small number of projects, but it's optional. Planning late can be made to work, but you have to have systems in place or you'll be in trouble. Be careful you don't throw the baby out with the bathwater by assuming planning ahead is the only way. Alistaire Cockburn did a survey of over 500 projects. He found only one success using phased delevery ("waterfall") approaches.

    Phased delivery (design, code, test, debug) can be very efficient if you are churning out fairly known solutions. For example, cranking out similar web sites or where a project can be fully specified and isn't too complex. Phased development is also high risk. Every error, especially early errors, are magnified. It's also high risk, because it doesn't respond to changes during a project lifetime. Given that requirements are always wrong, almost the first law of requirements, the incoming damage usually makes it a poor choice. Big-Design-Up-Front has a poor reputation these days. Check out the C2 wiki for some pretty damning criticism.

    To make evolutionary approaches work, on the other hand, you have to have code that can be easily changed. The tools to do this are unit tests and clean code (via code inspection and minimal design). If you do this then the tests can substitue for the now redundant documentation. Once you have clean, test covered code, you can throw away many other crutches. This in turn feeds back and allows you to change code easily. It's a very disciplined approach, a long way from "hacking". I think it's hacking that's left a bad taste in your mouth. The opposite of hacking is not necessarily planning.

    Once you can change code easily, you have less need to design ahead. You still design (more so, even), but it's blended with the coding process. Once you have less need to design ahead, then the code stays simpler for longer. This again feeds back into the agility.

    If the skills are there and the discipline is there, you can hum.

    Evolutionary design (agile) is a very resilient option well suited to the rough and tumble of web development, hence it's growing popularity, but it's not the only option. It's overkill for simple closed designs, but sometimes it's not fast enough. Read about the history of Flickr, or the "day off" strategy at Google. If time to market is key, then "hacking" may still be the best option. You have to plan the rewrite in, though.

    I can't quite bring myself to hack. I used to design ahead (I'm an ex-data modeller) and still lapse into that behaviour only to regret it later. In practice though, I go for agile with my paying clients. For web projects with changing requirements, it's usually in their best interest.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  3. #28
    SitePoint Evangelist
    Join Date
    Mar 2004
    Location
    Fort Lauderdale
    Posts
    522
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The waterfall analogy - it is old and no longer works and I agree with you - it is too strict and future changes in business logid are not easily implemented.

    but:

    I started this thread mentioning the concept: "GRAPPLE" a system that involves sequence, activity diagrams along with building classes. This is a very flexible strategy that involves everything mentioned in this thread but in an organized manner.

    Yes - diagrams are a must, use cases are a must. I thought that people on here would know what Grapple is - if not please look it up on Google.

  4. #29
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by photo312
    I started this thread mentioning the concept: "GRAPPLE" a system that involves sequence, activity diagrams along with building classes. This is a very flexible strategy that involves everything mentioned in this thread but in an organized manner.

    Yes - diagrams are a must, use cases are a must. I thought that people on here would know what Grapple is - if not please look it up on Google.

    Hmmm. Google says:

    Grapple :: Adam Kalsey
    I just tried a Grapple, an apple that is supposed to taste like a grape. ...
    I’d rather my child eat a grapple for a snack versus some of the other choices ...

    And I scanned throught the top 50 results and not one of them had to do with software development . I think I just learned never to name a project after an obscure fruit or to choose an acronym that is actually a common word.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  5. #30
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    No mention of GRAPPLE on c2.com nor on wikipedia, maybe you could try finding us a link?

  6. #31
    SitePoint Evangelist
    Join Date
    Mar 2004
    Location
    Fort Lauderdale
    Posts
    522
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Do a google search for "GRAPPLE, uml" and you will see.

  7. #32
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi.

    All I found was a reference to an old Sams book (with a broken link) and an obscure scientific paper. You need to do a bit more here than just "Google". Perhaps you could describe GRAPPLE as you understand it.

    In the obscure paper I found "Guidelines for Rapid Application Engineering" seems to be the acronym and it also seems to have been written around UML specifically. That's a bit tail wags dog, as even RUP doesn't mandate UML (although it's hard to avoid). GRAPPLE also has three steps before any requirements are gathered, and nine before the design phase. Academic papers on methodology are always a bit of a disaster, but this is waterfall gone mad . I really hope it's been misrepresented.

    Regarding use cases, no one is saying don't collect use cases. Quite the opposite, you want to maximise the benefit from them. Agile approaches merely start coding as the use cases come is, so as to give early feedback. Showing the customer and users the software always has a dramatic effect on requirements. It's better that this impact comes early.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  8. #33
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Showing the customer and users the software always has a dramatic effect on requirements. It's better that this impact comes early.
    Off Topic:


    Reminds me of many years ago, when a user used/tried software I had written. Had useful feedback like "Its c**p!", "It doesn't work". But that was because it reduced workload, to few hours a month. So someones job was in jepardy.

  9. #34
    SitePoint Addict
    Join Date
    Apr 2002
    Posts
    330
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by photo312
    I am creating an "on line personal training" application in PhP5. I am currently looking into UML and drawing up use cases, activity diagrams, classes, sequence diagrams and component diagrams.

    I have never used UML before and object oriented development is somewhat new to me from the php 5 perspective. ( coded in Java before ).

    I would like to use Smarty as the template engine.

    I haven't decided which php patterns I should use, but I know for sure I would like to focus on MVC ( Model View Controler ) and separate my objects into components.

    I wanted to get an opinion about how effective UML design will be in developing an application in PHP 5.
    I think you are in the right track to use UML. UML is just a visual language to express several types of aspects of system designs, but if you got at least to the point of modelling your system use cases, that will be really helpful to get you started with the implementation.

    Personally I use a methodology to implement use cases for PHP Web applications named "use case mapping". There is a lot to say about this methodology. I use it since 1999 when PHP 3 was first released with the OOP support. I also have given a few talks and post-graduate classes on the subject, but unfortunately the <advisor edit>Removed selfpromotional link</advisor edit>presentation slides are only available in Portuguese.

    I am working on a small document to explain how it works using a <advisor edit>Removed selfpromotional link</advisor edit> sample application but it should only be finished after this weekend. The sample application code can be browsed in its <advisor edit>Removed selfpromotional link</advisor edit> CVS repository.

    Anyway, to make a long story short, use case mapping is a methodology that defines on use cases are mapped to PHP classes and scripts.

    Basically, each use case is made at least of one Web script and one use case class. The Web script just loads all the involved classes, instanciates the use case class and call its methods. In case of some unexpected runtime error, the Web case script is also responsible to instanciate a special error use case class and call it to implement consistent error handling (read logging, notifying the admistrator, print friendly error messages, show useful information in debug mode, etc..).

    The use case class always implements the same interface. That interface consists of 3 public functions: initialize, process, output.

    The initialize and process functions implement the use case Control aspects. They could be just one function. They are split merely due to the convention that specifies that the initialize function should take care of verifying use case pre-conditions and the process function assures that the use case post-conditions are met.

    The output function obviously takes care of generating the use case result, which can be HTML pages, XML feeds, files for download, etc..

    The use case interface may also have some public variables to pass configuration values and return error detail information that the Web script may need to pass to the special error use case class. Each use case may also have private variables that can be used to share use case context information between the three functions above.

    As for the model classes, those should be separated. You can use as many as you need in each use case.

    The way all works in practice is that the Web script starts calling the initialize function and then the process function. Any of these functions may fail, so they return a boolean value. If they both succeed, fine, the Web script calls the output function and your use case is done. The output function may also use common view helpers that are implemented by separate classes and scripts to ease reuse among all use cases.

    The output function never fails. Anything that could fail due to an unexpected error (accessing a database, external system, etc..) must happen in the initialize and process functions. When these function fail, the Web script instanciates the special use case error class and calls it. That class is like any other use case class with the same functions and variables that I described.

    This may seem an unusual way to implement MVC because as you may notice I am not splitting the Control and the View in different classes. The reason for this is that usually the controller produces the information that is outputted by the view.

    Keeping the controller and the view in the same class simplifies information sharing a lot because it is done through use case private variables.

    Does this sound too abstract? Maybe, especially if you have never seen anything like this in practice. If you browse the CVS repository of the sample application that I mentioned above, you will find use case classes inside the <advisor edit>Removed selfpromotional link</advisor edit> usecases directory and the Web scripts in side the <advisor edit>Removed selfpromotional link</advisor edit> web directory.

    This is just to give you an idea of a consistent methodology that I use since 1999 as I mentioned. It has just been refined over the years. There are much more details than these. After all the post-graduate class that I was invited to give on the subject took about 2 hours. Feel free to ask if the explanation was not clear enough.

    Quote Originally Posted by photo312
    I am not aware of any forward engineering tools for php currently, so I know that my classes will not be able to be generated by "Poseidon Community Edition" for example.
    For mapping use cases I don't know any tools that are worth using. Some may be useful for generating model classes for persistent objects. Once I have seen something about "Executable UML" but I could not figure how it works in practice.

    Quote Originally Posted by photo312
    I am also using the GRAPPLE approach to application development. Please give me some suggestions and feedback on how I should effectively spend my time to prepare for the coding..
    I am not familiar with GRAPPLE. I searched with Google but I could not find any references to good public documentation on the subject. Just a few paper references. Any good URLs on the subject?
    Last edited by Helge; Feb 16, 2006 at 09:28.
    Manuel Lemos

    Metastorage - Data object relational mapping layer generator
    PHP Classes - Free ready to use OOP components in PHP

  10. #35
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I still fail to see many of the advantages of Agile Development and TDD; moreover, I've always had the feeling those are ways for less skilled people to achieve the results others reach by planning ahead in an organized way. So call me old-fashioned (or ignorant as many would and will) but I've always liked to compare software development with Arquitecture. It's not for nothing that Design Patterns are derived of Arquitecture theories, is my reasoning.

    Somehow I can't imagine an arquitect starting a project by placing bricks instead of planning ahead. There are lots of requirements that need to be taken into account before starting to build a building. Think of orientation for example. It is extremely important to get that right from the very beginning as it is "quite" difficult to just physically turn a building around because the arquitect failed to see where sunlight and wind were coming from before he started.

    I had never heard of GRAPPLE before, but in general it seems like a quite logical process to me. I'm also for using UML to lay the foundations and theoretical concepts of a project and to get what you call a "bird view" of the requirements. The fact that UML is also not binded to any programming language in particular gives you also the chance IMHO to choose the tool that best fits the job before starting. You might have thought of PHP being the right tool but end up realising you should be using Java/.NET instead, for example, while that would be quite hard to achieve when you start by coding and choosing the tool first. I don't think migrating to another language once you've finished the job is something anybody would enjoy much.

    And remember that the process of abstracting the concepts to the highest level is not something everybody is able to. As a matter of fact, it is quite the opposite.

    Then again, take my comments with a grain of salt. Nevertheless, I'm not a Ph or a Dr or hold any degree whatsoever. Just a humble guy who ever started into this arenas by making a "Hello World!" in HTML 3.2, certainly not the reference many would be waiting for
    There’s more than one way to skin a cat.

  11. #36
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Maybe OT -- I'm not so willing to discard agile development methodologies. At the same time (and perhaps because of my age) I do think that aspects of "older" methodologies have much merit that are sometimes forgotten. One thing I have tried to remember is that highly technical crafts tend to have a lot of art involved in them just as artistic endeavors tend to have a lot of technical craft in them. There need be much planning but there also is a need to be adaptatable both to available skills and changing needs based on the continuous feedback of outcomes. I like to think that there is a good analogy between film making and software development. The important part for me is that even the most creative of films starts with a simple story; then a detailed story board is developed; then a budget and a timeline is deduced and and finally the production process begins. Typically any and all of the preceding items will be altered at that stage based on talents and feedback -- but always to a limit I think only a rare genious could make a film without elaborate planning and I think it is the same for software and really, any type of technical/artistic endeaver. There is a great feeling to be gained from "coding first" but if you have a lot of coding experience you probably already know what works and what doesn't in a given situation; moreso you probably realize that initial planning is harder, less fun and ultimately more productive than pure experimentation. That said, flexibility to respond to unanticipated results is an important realization that is gained from the agile methodoligies.

  12. #37
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm not so willing to discard agile development methodologies. At the same time (and perhaps because of my age) I do think that aspects of "older" methodologies have much merit that are sometimes forgotten.


    I'm not saying that being agile, or not is a good or bad thing, I'm saying that I think a lot of people just get hung up on it; They easily forget that there were methods before agile became common practice.

    I think that if you go down one route, and only that one route, whatever that route is, you are limiting yourself, in that the disadvantages may well outweigh the actual advantages of what your choosen route offers you, in the end

    You need flexibility as much as what best practices there are, as I see it.

  13. #38
    SitePoint Zealot Christiano's Avatar
    Join Date
    Apr 2005
    Location
    Belfast, North of Ireland
    Posts
    153
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I feel prototyping is essential to accurately identify the needs of your system without chausing chao's with problems on its release.

    I also feel agile development would only be adaptable in a professional and _EXPERIENCED_ systems development environment, as It seems to rely on teamwork in heavily my opinion. I tend to push more to the RAD methodologies they seem much cleaner and feedback oriented which is essential in delivering not only a great system, but one that meets the requirements of the system sponsor.

    -Martin
    Innovative Design and Development Services
    Design: XHTML - CSS - Photoshop CS - Flash 7 - Illustrator
    Development: Java - JavaScript - PHP - MySQL - .NET - Struts 2

  14. #39
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by nacho
    I still fail to see many of the advantages of Agile Development and TDD;
    The advantages are similar to "lean manufacturing" and "total quality management" and "just in time" in other industries, as compared to centralised control. It's lower risk, but slightly slower than the plan ahead method. On complicated problems though, it's essential. Plan ahead is fragile, as no amount of genius can comprehend 100+ class systems in their entirety. Agile is an adaptive system, often with only 1-2 week iterations, and scales well with complexity up to about ten people.

    Quote Originally Posted by nacho
    moreover, I've always had the feeling those are ways for less skilled people to achieve the results others reach by planning ahead in an organized way.
    Unfortunately (as jayboots touched on in the post after yours), it actually takes skilled practitioners with a some degree of design skill to make it work. I find less skilled developers need a lot of coaching, not in agile itself, but in object modelling and OO design.

    Because you put the design in as you go, after the code is "working", it's easy to check in not so good code at the end of the day. That's where it takes a skilled, and slightly perfectionist coder, to have the will to put the design in. Otherwise progress gets slowere and slower and you are really hacking. The whole idea is that by injecting good design constantly, you can keep the code fluid. The will to refactor is vital.

    The payoff is huge when you can keep it on course.

    I find the people who get on with agile the most are those that have seen planned projects fail. When they go, they really go. The respond to change and error with more planning, slowing down the feedback rate and so increasing the likleyhood of mistakes and change. In practice the developers will sniff trouble and abandon the process, faking it to their managers. E.g. UML is written after the code, changes aren't documented and the docs go out of date, etc, etc.

    For example Andy Pols, Chris Matts, Eric Evans and Martin Fowler are all strong agile proponents. All come from an anaylist background.

    Quote Originally Posted by nacho
    So call me old-fashioned (or ignorant as many would and will) but I've always liked to compare software development with Arquitecture. It's not for nothing that Design Patterns are derived of Arquitecture theories, is my reasoning.
    But code is maleable, and building is a poor analogy (as is engineering). You can copy the "house" with a single mouse action. Programming is a design activity. Basically we are building blueprints, not actual buildings. The install script is the building firm, and they work at no cost.

    Quote Originally Posted by nacho
    Somehow I can't imagine an arquitect starting a project by placing bricks instead of planning ahead.
    Do you really think they plan the design process? Do you think they say "for the first two weeks I will be designing the floor", then "the last three weeks will be for the roof"? No chance. The design process will start with a rough sketch, they will take it back to the client to discuss it, the drawing will be refined and back to the client they go.

    The deliverable for the architect is a drawing and a build plan. The deliverable for us is code - a drawing for the computer.

    Quote Originally Posted by nacho
    And remember that the process of abstracting the concepts to the highest level is not something everybody is able to. As a matter of fact, it is quite the opposite.
    Even a slight increase in complexity seems to make the job a lot harder.

    When the task is simple, or just a slight stretch, then the act of designing it all in one go is thrilling. You completely understand the problem and you just cannot type the code fast enough. Damn it, it just has to be the right way.

    The complexity mounts up fast. If you record the diagrams in a compicated problem (15classes + should do the trick), in CVS say, and watch them change during a project, it can be quite a shock. It's even worse with several developers involved. So much is not drawn, because of tacit assumptions. You rapidly get design drift and have to recoordinate, typically within a day or two. The insight from the drift often causes a bit of a rethink. Suddenly two developers had a "right way".

    Quote Originally Posted by nacho
    Then again, take my comments with a grain of salt. Nevertheless, I'm not a Ph or a Dr or hold any degree whatsoever. Just a humble guy who ever started into this arenas by making a "Hello World!" in HTML 3.2, certainly not the reference many would be waiting for
    Well, my degree was in physics. Still, this is craftmenship stuff, and you have to learn by doing.

    At the PHPLondon user group we run a small project that is open to everyone. A group meets at someone's house on a Saturday afternoon, and code for a few hours. With 1 hour iterations, CRC sessions (whiteboards are unlikely), pair programming and acceptance tests, it gives newcomers a chanceto experience agile techniques first hand. From that they can take away techniques that are useful for them. Agile techniques, if not whole agile systems, have become popular in the group.

    There is no substitute for trying it out.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  15. #40
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Dr Livingston
    You need flexibility as much as what best practices there are, as I see it.
    It's rather strange that this topic comes up just as I'm writing an article on it (Feb. PHP|Architect). I am hoping to apply a "sense making" tool to the problem. I think I've got most of the trouble nailed, so it should be a good one to finish my tenure on.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  16. #41
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:


    Quote Originally Posted by lastcraft
    to finish my tenure on.
    :'( :'(

    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  17. #42
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    First of all, I wasn't try to say anyone should discard any development method. I try by means of my own sig just to say the opposite. IMHO, it all comes to your own circumstances/situation.

    Quote Originally Posted by lastcraft
    Plan ahead is fragile, as no amount of genius can comprehend 100+ class systems in their entirety.
    I appreciate you take the time to discuss my point of view, but this statement won't cut it for me. Being a genius, or being able to comprehend 100+ class systems is a relative term. For some, an impossible achievement, for others, a piece of cake. I see the added value of working in pairs or using a CRC cardset for people that otherwise would feel lost in the vastness of a system; but that doesn't mean it has to apply to everyone.
    By means of productivity in an enterprise environment it is certainly a measure that will help to get the most out of the employees involved, but then again, I feel certain tasks, such as designing the system to be developed, would always have to be reserved to a constrained group of developers, as not everybody is likely to have the same capabilities. As the time of implementation arrives, it will almost surely help to use Agile procedures to get the job done. In my case though, the task of implementing is carried out by a very small group of people.

    Quote Originally Posted by lastcraft
    Because you put the design in as you go, after the code is "working", it's easy to check in not so good code at the end of the day. That's where it takes a skilled, and slightly perfectionist coder, to have the will to put the design in. Otherwise progress gets slowere and slower and you are really hacking. The whole idea is that by injecting good design constantly, you can keep the code fluid. The will to refactor is vital.
    Somehow I get the feeling we both speak the same terms, we just use other words; you do recognize the importance of designing before hand in order to be able to achieve the best implementation. Refactoring, as code improvement, falls outside the design frame. I certainly think it is very important to constantly being able to improve your code by means of profiling and analizing possible shortcomes, but as long as the requirements are still met by the overall design of the application, the focus resides on the implementation, and I was referring exclusively to the design phase.

    Quote Originally Posted by lastcraft
    In practice the developers will sniff trouble and abandon the process, faking it to their managers. E.g. UML is written after the code, changes aren't documented and the docs go out of date, etc, etc.
    With all due respect, generalizing in these terms is making a somehow bold statement. If this has happened to you so often that you consider it to be "true", I have only to add that you are working with the wrong kind of people; or in case you are responsable of hiring up, you somewhat failed to evaluate your staff in a proper way. To me, the personal attitude of an employee is by far more important that the knowledge he/she might have. Knowledge is adquirible, the right attitude (e.g. not hiding up when problems arise) is intrinsic to the indidual.

    Quote Originally Posted by lastcraft
    For example Andy Pols, Chris Matts, Eric Evans and Martin Fowler are all strong agile proponents. All come from an anaylist background.
    And I won't go into saying they've got it wrong, but I will still make my own decisions and keep on being critical on about everything I read/listen to. Taking their (or other's) meanings for granted truths can be as dangerous as religious extremism. In my view, nobody holds the truth, as we all have our own.

    Quote Originally Posted by lastcraft
    But code is maleable, and building is a poor analogy (as is engineering). You can copy the "house" with a single mouse action. Programming is a design activity. Basically we are building blueprints, not actual buildings. The install script is the building firm, and they work at no cost.
    I'll agree with you the analogy gets poorer as you go further into the implementation. But I was referring to the developing process as a whole. Nonetheless ans as you may well know, it is possible to build prefabricated buildings to some extent, which would be comparable to reproducing different instances of the same (or similar) application(s). Being an experienced developer as you are you would know that having to change a system entirely once it's been deployed is a no-go.

    Quote Originally Posted by lastcraft
    Do you really think they plan the design process? Do you think they say "for the first two weeks I will be designing the floor", then "the last three weeks will be for the roof"? No chance. The design process will start with a rough sketch, they will take it back to the client to discuss it, the drawing will be refined and back to the client they go.
    Well, I do. I happen to have arquitects quite close, within my family as well as within my ring of friends. As you as well point out, the design process will take the very first step, whether that means they'll have to re-design the original planning is not relevant to the discussion IMHO. What they certainly won't do is start by placing bricks and going to the client for approval to have to demolish what it's been built because it didn't fit the original purpose.

    Quote Originally Posted by lastcraft
    The complexity mounts up fast. If you record the diagrams in a compicated problem (15classes + should do the trick), in CVS say, and watch them change during a project, it can be quite a shock. It's even worse with several developers involved. So much is not drawn, because of tacit assumptions. You rapidly get design drift and have to recoordinate, typically within a day or two. The insight from the drift often causes a bit of a rethink. Suddenly two developers had a "right way".
    I happen to be working on a system that at the very first stage (it is really basic at the moment) closes to 50+ classes. I bet I could write it from scratch without taking a look at the original and it wouldn't differ much from it. That being said, it doesn't make me a genius at all. I have just been involved in it for so long.
    I agree with you that the amount of developers involved is always going to be inversely proportional to the effort needed to achieve the goals, specially when all of them hold the right to make decissions. That's why I pointed out that some tasks should always be reserved to a small group of capable people. Whether that is practically achievable, that is, you are able to find those people, is another problem all together. In fact, I feel that is exactly what Agile Development is able to resolve, the scarceness of people with certain capabilties. Of course, I could have it all wrong.

    Quote Originally Posted by lastcraft
    Well, my degree was in physics. Still, this is craftmenship stuff, and you have to learn by doing.
    Been there, but I never got any further than the first year (I spent the rest of the time having the heck of a nightlife), so you surely beat me there .

    Still, I feel we do agree to a point (and no, I don't mean only sitepoint ). As you well say "there is no substitute for trying it out".

    Off Topic:

    London it's a bit far away of my current domain, but I'd enjoy visiting your user group for the sake of curiosity.


    PS.- I apollogize to the rest of the participants of this thread if I extended myself too much on my answer and I concentrated on lastcraft's comments, but having quoted me as often as he did I felt entitled.
    There’s more than one way to skin a cat.

  18. #43
    SitePoint Guru silver trophy Luke Redpath's Avatar
    Join Date
    Mar 2003
    Location
    London
    Posts
    794
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by nacho
    I still fail to see many of the advantages of Agile Development and TDD; moreover, I've always had the feeling those are ways for less skilled people to achieve the results others reach by planning ahead in an organized way.
    In saying that you are ignorantly dismissing a lot of smart and experienced people who use and advocate Agile Development and TDD.

    Somehow I can't imagine an arquitect starting a project by placing bricks instead of planning ahead. There are lots of requirements that need to be taken into account before starting to build a building. Think of orientation for example. It is extremely important to get that right from the very beginning as it is "quite" difficult to just physically turn a building around because the arquitect failed to see where sunlight and wind were coming from before he started.
    The mistake you are making here is by comparing designing software to buildings directly. Yes there are similarities but there are also differences. You are right it is very difficult to change things down the line with buildings - this is not the case with software, especially if you have a good suite of unit tests.

    The other mistake you are making is thinking that in agile development there is no planning. There is planning, but only as far ahead as the current iteration. In agile development you don't plan out the whole project in advance because the project could change. Clients could change their mind about the way they want things, remove features or add features based on the output of each iteration. The client always gets something new at the end of each iteration and is able to change their mind about things (and they usually do). By only committing to an iteration of work, and not planning the whole thing in advance, you greatly reduce the cost of change and make things much more flexible.

  19. #44
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Luke Redpath
    In saying that you are ignorantly dismissing a lot of smart and experienced people who use and advocate Agile Development and TDD.
    Being smart and/or experienced does not make anybody right. As I said, I didn't try to discard any methodology. I was trying to point out to the diversity of posibilities. As long as somebody tries to convince there is only one way to achieve something, it gets smelly to me.

    Quote Originally Posted by Luke Redpath
    The mistake you are making here is by comparing designing software to buildings directly. Yes there are similarities but there are also differences. You are right it is very difficult to change things down the line with buildings - this is not the case with software, especially if you have a good suite of unit tests.
    Of course is not THE_SAME, but I don't recall having said that. If the requirements of a system change through its lifecycle and those changes affect the system in a susbtantial way, you will have to rewrite, whether you use unit tests or not. Unit tests are useful in certain circumstances, in others they're just redundant.

    Quote Originally Posted by Luke Redpath
    The other mistake you are making is thinking that in agile development there is no planning. There is planning, but only as far ahead as the current iteration. In agile development you don't plan out the whole project in advance because the project could change. Clients could change their mind about the way they want things, remove features or add features based on the output of each iteration. The client always gets something new at the end of each iteration and is able to change their mind about things (and they usually do). By only committing to an iteration of work, and not planning the whole thing in advance, you greatly reduce the cost of change and make things much more flexible.
    Again, English is obviously not my native language, but I don't recall having said that either. As long as the client has not made his/her mind up, I don't have much work to do. But as soon as they have, they will sign a contract establishing what the requirements are. If they change their minds once the work is started, I surely won't be the one paying the bill for the extra time involved in changing the requirements.
    You probably won't like the example, but try going to a restaurant an order something. Then when the order is taken and the kitchen is already working on it, try telling the waiter that you have changed your mind about what you have ordered and see who pays the dish(es).
    And no, I'm not saying software development is THE_SAME than running a restaurant.
    There’s more than one way to skin a cat.

  20. #45
    SitePoint Guru silver trophy Luke Redpath's Avatar
    Join Date
    Mar 2003
    Location
    London
    Posts
    794
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by nacho
    Again, English is obviously not my native language, but I don't recall having said that either. As long as the client has not made his/her mind up, I don't have much work to do. But as soon as they have, they will sign a contract establishing what the requirements are. If they change their minds once the work is started, I surely won't be the one paying the bill for the extra time involved in changing the requirements.
    You probably won't like the example, but try going to a restaurant an order something. Then when the order is taken and the kitchen is already working on it, try telling the waiter that you have changed your mind about what you have ordered and see who pays the dish(es).
    And no, I'm not saying software development is THE_SAME than running a restaurant.
    The idea of agile methods is to make it easy for the customer to change their minds because quite frequently the customer never knows exactly what they want at the beginning. With agile methods there shouldn't be a huge bill for changing the requirements. In fact, your comment only serves to highlight why fixed-price contracts with rigid requirements that cannot easily change, coupled with big up-front design, are a bad thing.

    The example of the restaurant is completely irrelevant as it cooking a meal has nothing to do with software design.

  21. #46
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Luke Redpath
    The idea of agile methods is to make it easy for the customer to change their minds because quite frequently the customer never knows exactly what they want at the beginning. With agile methods there shouldn't be a huge bill for changing the requirements. In fact, your comment only serves to highlight why fixed-price contracts with rigid requirements that cannot easily change, coupled with big up-front design, are a bad thing.
    While that might serve you, it doesn't have to apply to everyone. That is the difference between your view, and mine. You tend to think that what it's valid to you must be valid to everyone, but it only shows a rather shortview on how things work IMHO.

    I'll try to avoid at all costs that the client thinks he/she might change the requirements twice a day just because the flexibility of the process. The requirements in my case are not more or less rigid than in yours, nor it is the ability or ease to change them. Flexibility comes within the arquitecture of the system been built, nor with the methodology being used to build it.

    Quote Originally Posted by Luke Redpath
    The example of the restaurant is completely irrelevant as it cooking a meal has nothing to do with software design.
    Somehow I get the feeling you want so bad to reafirm your own convictions that in the process of trying to ridiculize the arguments that do not suit your view (instead of trying to use real arguments) you forget to read properly. The only thing I can make of it is that you must be one of those I was talking about earlier, unable to scope to the highest level of abstraction. But don't worry, it's nothing you should be ashamed of, and I understand it.
    There’s more than one way to skin a cat.

  22. #47
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have recently become a proponent of the building analogy when it comes to software developmen. The trouble is that most of the people, when comparing the two activities, compare actual programming with the actual building, just like our nacho here. But as Marcus nicely stated it, programming is part of the design, not the actual building -- the latter is done by automated tools like compilers, build scripts etc.

    So: nacho, when you say that the architects don't make the building and go to the clients for approval and then demolish the building and make a new one, wou are correct, but it has nothing to do with making software. What architects do is they go to the clients with plans and models -- and this is exactly what the software developers do.

    Imagine that you are an architect, and you find a construction company that is able (say the employ a bunch of wizards ) to build a complete house from scratch in a few minutes, with the cost of material and their work measurable in cents? Would you then just take the client to the building, and when he says I don't like it you would tear down the building, change your blueprints and then make the wizards build the new one? That's what it's like in software development.

    Keep in mind, the final product of a building construction process is a final building. The final product of the software development is not source code; it's the actual running program.

  23. #48
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Unit tests are useful in certain circumstances, in others they're just redundant.
    Personally, I'm not particularly test infected yet, but even I can see that that statement is very bold, to have been made

    I've not come across once, where unit testing hasn't helped me...

  24. #49
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by nacho
    Somehow I get the feeling you want so bad to reafirm your own convictions that in the process of trying to ridiculize the arguments that do not suit your view (instead of trying to use real arguments) you forget to read properly. The only thing I can make of it is that you must be one of those I was talking about earlier, unable to scope to the highest level of abstraction. But don't worry, it's nothing you should be ashamed of, and I understand it.
    That's one way to look at it, but a rather pessimistic one, and frankly I think Luke has a point here. Software rarely has a rigid specification that will never change or require new features. It's not a meal in the sense that you order something, eat and be done with it. What if you had to live with the meal of your choice and its design for months or possibly years?

  25. #50
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @BerislavLopac
    I guess I'm not expressing myself that well . I'm not talking about every aspect of building a system, nor of constructing a bulding, but about core requirements. Of course you'll have to show your client what progress is being made, and keep discussing how that progress fits into the original requirements, but the main ones will remain.

    If the requirements involve a web application, I already have a core application that will be used, regardless of what the rest of the requirements are. This application will be based on the HTTP protocol and will imply a serie of components that are built around the core application. If the client decided once the project is started that he/she instead prefers a desktop application, for whatever reason, I shall reproduce the costs of that change of requirements into the client's bill. No doubt about it.

    If the client instead expresses a desire to change certain business logic rules, that is obviously not going to make me start all over again, and therefore I won't push the bill of that little extra time forward to the client. If I didn't know what service meant I would have never made it this far.

    In the building analogy, I'm talking about core changes to the requirements that would affect the way the building is physically built. It is obvious to me that no arquitect would make a (big) problem of having to place a window where there was not one, once a project is started. But try to tell him/her that you want a third floor once the roof is in place ...

    Of course the analogy is not 100% comparable, but I assumed (now I see wrongly) that it would be clear form the very beginning.

    The flexibility, as far as I'm concerned, of changing a system (to a certain degree) has nothing to do with the way you choose to build it (whether you choose to apply TDD or not, or whether you work in pairs or not, or whether you use CRC cardsets or you prefer to remember it all), but with how flexible that system is thought of in its arquitecture and with how the different components of that system are (de)coupled to/of each other.

    Quote Originally Posted by Dr Livingston
    Personally, I'm not particularly test infected yet, but even I can see that that statement is very bold, to have been made

    I've not come across once, where unit testing hasn't helped me...
    You say it yourself, YOU have not come across once where it hasn't helped you. I don't think I need to add much to it, except that your statement is at least as bold as mine could be.

    Quote Originally Posted by Ezku
    That's one way to look at it, but frankly I think Luke has a point. Software rarely has a rigid specification that will never change or require new features. It's not a meal in the sense that you order something, eat and be done with it. What if you had to live with your chosen dish and its design for months or possibly years?
    Again, analogies are not 100% accurated, that's why they're analogies, so of course anybody can make a point out of it. But if you honestly try to be constructive you would read that comparison otherwise and would not try to ridiculize it in a way that does nothing to do with the original purpose. Does somebody really think I'm saying software development is like cooking, or like running a restaurant? I'm really starting to wonder how some people are able to be successfull in this business while having such a closed mind ...
    There’s more than one way to skin a cat.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •