SitePoint Sponsor

User Tag List

Page 3 of 4 FirstFirst 1234 LastLast
Results 51 to 75 of 86

Thread: UML, PhP 5, MVC

  1. #51
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Beg my pardon, but I meant that unit testing has helped me, I should be more clear on that point, if that wasn't exactly clear enough for you; If you actually care to read the first phase of that paragraph I posted earlier

    I've not come across once,...
    Note the meaning of the word not in reference to the whole paragraph; What is actually happening, grammically speaking that is, that the first phase negates the second phase of the paragraph.

  2. #52
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I had understood actually Dr. Livingston, it's just that in my case I have still found no use to it. Eventhough it does make sense to so many people, I seem to be up till now the exception to the rule.

    While I'd think that does not make me any better or worse developer than other, the opposite seems to be the general consense.

    I'll like to add my excuses to those involved in the discussion with me as it also seems I'm not able to express myself in a valid way, as frustating as that is. My examples seem to be not any good and therefore instead of adding any value to this thread we keep arguing in circles.

    I rest my case and will try to keep my mouth shut in the future, once again.
    There’s more than one way to skin a cat.

  3. #53
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    I find the people who get on with agile the most are those that have seen planned projects fail.
    Failure is the best teacher. I pity anyone without a spectacular failure in their portfolio.

  4. #54
    ********* 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
    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.
    Yes. Each methodology has a level of efficiency, it has an envelope and it has failure modes when it goes outside that envelope. I wouldn't want to argue that a design in one go solution for a closed form problem is not the best. Indeed it will be the most efficient. Examples would be reporting applications, or repeating similar solutions over and over in e-commerce.

    What I would hope to demonstrate, and from my own direct and consultancy experience I find a no-brainer, is that agile has a broader envelope. I'd also like to show that agile approaches are more suitable for the rough and tumble of evolving web businesses. I won't be able to do that with refactoring being out of your current toolset, but perhaps I could challenge the notion that planning is the only way.

    Quote Originally Posted by nacho
    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.
    This is wishful thinking. Even with encapsulation, there is an n-squared component.

    I used to be lead architect for 100 table datamodels, and was lead developer when I had my own software company. In both cases 100+ object systems were common. When you build data models you are pretty insulated from the outside world, but even here when the software started to be used, typically 50%+ of the model needed to change. Changing data models is expensive, so we would try and counter this with business analysis sitting next to the client, and scenario analysis. After all that we still kept having to change just as much stuff. The closer we got to what the client actually wanted, the worse we got. Our client liked it though, so the powers that be were happy. You only have to port data a few times, before you take a just in time attitude.

    When I had my own company, and was doing the requirements and analysis myself, things just got worse. Every meeting leads to something different. My early attempts to cope with this were bad. We either had a change cost, we had fewer meetings (yuk), we had formal specs, we had paper mock-ups, and I would write the spec with the client. Well, their eyes glaze over after an hour or three (something really apparent when you are sitting next to them) and they rush it. I would make mistakes too, of course. After all that, the spec was still wrong and we got accrimonious tails to projects. I vowed never to be in that situation again.

    Yet I don't think I am a bad data or object modeller. I thought I was a great modeller at the time, and could do 100+ classes whilst chewing gum. Now I know that's not true. Every model is chock full of assumptions about the domain which are plain wrong. The understanding only comes about iteratively, one you and the client can see how the model works. No model survives a meeting with the client.

    The secret is it shouldn't. They will be thinking about it too. They will have ideas and come back to you a few days later, and these ideas are really valuable. If they are valuable to them, you have a happy client at the end of the project. You want to embrace those changes.

    Quote Originally Posted by nacho
    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.
    At some point the system is big enough that it is always lost to everyone. All I have to do is keep making the project bigger, and design up front is doomed to fail. The complexity simply cannot be held by one person. Agile is about resilience in the face of complexity and change. It's limit is the number of people and their communication, not vaugeness of goal or modelling error.

    Quote Originally Posted by nacho
    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.
    The so called surgeon model, or the "over the wall" model. The phrase "would always have to be reserved" is telling here. Why?

    We have a mixed ability development group, ranging from three years OO and design experience to twenty. Everyone contributes to the design process, either ad hoc meetings, or in pairs refactoring. We keep the design level high with constant mentoring, and code review if we haven't rotated the developers enough on a secton of code.

    The level of design is high, and actually increases as features are added to the system. Our usability guy is right next to us and can suggest changes, even fundamental ones, at any time. The act of making these changes adds the necessary flex points to the design. Our designs are either simple or flexible. We never get big inflexible ones (not counting some legacy stuff).

    It works.

    Quote Originally Posted by nacho
    Refactoring, as code improvement, falls outside the design frame.
    No .

    Refactoring is not just tidying the code. This is not purely an implementation process. Quite dramatic design changes are possible, even encouraged, by this.

    Refactoring for us is the design "stage". This is 100% opposed to the idea of a phased process itself. We blend test/design/code with continual requirements gathering (the project I am thinking of is in-house). If we do any design sessions before code, it's either because it's a version two and we know a lot about the problem, or it's to coordinate a group to all pull in the same direction. The "plan" can be torn up at the first serious problem, in which case we recoordinate and carry on.

    Design meetings are imparting a rough vision here or a core idea, not a detailed design. Our longest design session was in the pub, and lasted two hours. Often refactoring coupled withteh odd five minute meeting are enough.

    Quote Originally Posted by nacho
    and I was referring exclusively to the design phase.
    So am I.

    You have to put out of your head that agile stuff is about hacking, as it certainly isn't, It's a highly skilled and disciplined activity. It's hard work being flexible with repect to requirements. It's the client that's winning here, not lazy developers.

    Quote Originally Posted by nacho
    With all due respect, generalizing in these terms is making a somehow bold statement.
    Yes it is bold, and yes I've seen it happen, so I feel entitled to say it. It's not proveably true for every project ("all swans are white"), but try this. Take a design that you did in the past that the developers should have followed, the one before the first line of code. Look at the corresponding code now (after some maintanence, as you can always crack the whip right up to reality of the client demo).

    Is it identical? You have to come up with a truly random selection for this to work, because of natural bias. Roll a dice on a class name list or something.

    Try it with comments, as they are usually even worse. Just randomly choose some code, especially stuff that gave trouble. Do the comments match code?

    I'll bet there is some drift. I even bet there is a lot of drift.

    Quote Originally Posted by nacho
    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.
    I assure you, all the developers (not the management ) were 100% professional and well intentioned. It was because they were well intentioned and had pride in their work, but under time pressure, that they would be bucking the system. Far worse is to find sarcastic comments in your code:
    http://www.twelve71.org/blogs/rachel...es/000842.html

    I am going to exagerate your argument here...

    Your attempt to shoot the messenger, by claiming that the people I work with are lazy or I am too stupid to model, are not really going to hold water. Again, the likes of Martin Fowler adopt this methodology. Implicit in that is an admission of their own failings. Just because I admit previous projects have had problems, and that I don't have a modelling crystal ball, does it make it our (my) fault? Even if it does, that's an admission that design up front is fragile.

    ...OK, you didn't exactly say this.

    Design up front is a is kind of Taylorism. You have time management experts figure everything out so that the plebs man the production line. The plebs have to be controlled by managers and QA and sacked if they make mistakes. Taylorism has since been wiped out everywhere except sweat shops and the software industry.

    Now we have quality systems from Japan that emphasize fixing the process when there are mistakes. the Total Quality" movement have a lot in common with agile, as does the "theory of Constraints". People don't want to make mistakes and don't like it when they do. If they are, it's a management problem.

    Quote Originally Posted by nacho
    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.
    Everybody is critical of other people ideas, it's being critical of your own that's difficult. From where do you get this assumption that planning is absolutely necessary and that any failure is due to stupidity or a planning failure? It means you respond to planning failures with more planning.

    Could you write a plan for children to enjoy themselves at a Christmas party?
    Could you plan a military engagement?
    Could you plan this conversation?

    Quote Originally Posted by nacho
    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.
    We've done it. We moved from a database architecture to a messaging architecture last year. We are currenty completely rewriting the front end legacy web system and we are doing it one piece at a time. Far from being no-go, it's a non-problem.

    To give you an idea of how much work is invested in getting "agile": a developer can come in first thing, pair with someone if available, fix the most immediate outstanding requirement and roll out to the server groups. We trust them implicitly to do this (we can always undo a mistake after all). Besides, they cannot roll out without passing all the tests (5500+).

    The shortest time from update to live could be under an hour, thanks to the toolset.

    Quote Originally Posted by nacho
    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.
    You missed the point here, but others have picked up on it.

    Quote Originally Posted by nacho
    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.
    Is there any way we could see the design before and after?

    Actualy that's not the point. The point is, how much will the model change during development and maintanence. Also it depends on project domain. I could build a reporting application, such as a view on the accounts, from start to finish without problem and have done. (Actually, even then I would have 20% or so adjustment just because I would find better ways of doing things by the end). That's a limited class of problems though. I enjoy the hard ones.

    Quote Originally Posted by nacho
    In fact, I feel that is exactly what Agile Development is able to resolve, the scarceness of people with certain capabilties.
    The problems are still the same. In fact it raises the bar to entry, because of the shared code ownership. We go to ridiculous lengths to keep people out.

    Quote Originally Posted by nacho
    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.
    It's well worth visiting. Are you coming to the conference?

    Quote Originally Posted by nacho
    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.
    This is a discussion forum. I am sure know one will begrudge us a discussion . Besides, it's the long posts that get deeper into the issues.

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

  5. #55
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'll bite for the last time.

    Quote Originally Posted by lastcraft
    I wouldn't want to argue that a design in one go solution for a closed form problem is not the best. Indeed it will be the most efficient. Examples would be reporting applications, or repeating similar solutions over and over in e-commerce.
    That's exactly what I mainly do, so I was probably comparing apples to oranges. The difference is huge when you can dream the domain. In my case, planning is the way to go.

    Overall, I see now how our constraints are totally different, but that was actually kind of my point. Because not everyone works with the same constraints there is no way a certain methodology is going to be valid for all of us.

    Quote Originally Posted by lastcraft
    Everybody is critical of other people ideas, it's being critical of your own that's difficult. From where do you get this assumption that planning is absolutely necessary and that any failure is due to stupidity or a planning failure? It means you respond to planning failures with more planning.
    I respond to planning failures with better planning, as opposed to more planning. More is not always better and if it's not better is not useful.

    Quote Originally Posted by lastcraft
    Could you write a plan for children to enjoy themselves at a Christmas party?
    Could you plan a military engagement?
    Could you plan this conversation?
    I could but I would fail to achieve the goals because those are not tasks to be automated.

    Quote Originally Posted by lastcraft
    To give you an idea of how much work is invested in getting "agile": a developer can come in first thing, pair with someone if available, fix the most immediate outstanding requirement and roll out to the server groups. We trust them implicitly to do this (we can always undo a mistake after all). Besides, they cannot roll out without passing all the tests (5500+).
    I consider this to be implementation, and not design. From what I understand of what you're saying I have it wrong though.

    Quote Originally Posted by lastcraft
    Also it depends on project domain. I could build a reporting application, such as a view on the accounts, from start to finish without problem and have done. (Actually, even then I would have 20% or so adjustment just because I would find better ways of doing things by the end). That's a limited class of problems though. I enjoy the hard ones.
    Exactly, it depends. And of course the implementation would vary, but I was talking about core concepts. It is a limited class of problems, but it is also as hard as I go at the time being.

    Quote Originally Posted by lastcraft
    It's well worth visiting. Are you coming to the conference?
    Unfortunately, not a chance.

    Thanks again for taking the time and explaining.
    There’s more than one way to skin a cat.

  6. #56
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by nacho
    But try to tell him/her that you want a third floor once the roof is in place ...
    You're again missing the point completely, and confusing design with build.

    What would they say in that case? They would say no problem, we'll tear down the building, make new static calculations and build the building back with the new design. Where is the problem? It's free and takes no time!

  7. #57
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by nacho
    I consider this to be implementation, and not design. From what I understand of what you're saying I have it wrong though.
    The main problem is that you're confusing implementation with building. Programming (implementation if you like) is part of the design, as each individual programmer inevitably makes some individual choices, no matter how precisely the original design was specified: to use one function instead of another, to use do...while instead of while...do loop, to use a Web link instead of a button etc.

    In comparison to the architecture, programming ("implementation") is the equivalent of the engineering work calculating the building's static etc, which is still part of the overall design. It is not the last phase in a development process after it comes the actual construction, and here's the main difference: while with buildings it is both lengthy and costly, with software it costs virtually no money or time.

  8. #58
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    The main problem is that you're confusing implementation with building.
    Yes, in your terms I do , although I'm not sure it is confusion or the wrong choice of words. In any case you're surely right about what you're saying, but I still see design as the theoretical conception against programming/implementation as the practical application of the concepts. I might have to polish my English and eat up a couple of books before I open my mouth again
    There’s more than one way to skin a cat.

  9. #59
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nacho, if you're interested in a good overview of the thinking behind Agile development, two very interesting reads are Martin Fowler's articles The New Methodology and Is Design Dead?. Incidently, both of them explain why comparing software engineering to any other kinds of engineering is wrong.

  10. #60
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'd like to start offering my apologies to photo312 for hijacking his/her thread. It is never been my intention but nevertheless it is clear now this thread has become some kind of Agile vs. "Conventional" Development discussion that differs from what he/she probably had in mind.

    So, going for a moment to the original purpose of the thread, I'd like to add the following. One of the things it's not been mentioned up till now, as far as I recall, is that there is a practical difference between the use of UML up front with PHP and for instance Java (I don't know much about .NET). The main practical difference, as I see it, and of course, as many times before I could have it all wrong (and I might have laid some bait for self-promoted tools ), is that in PHP there is no tool to automatically generate code from UML schemas, while in Java you do have several tools to achieve that. (I won't go either to evaluate whether the different solutions are better or worse; as I understood photo312 has a Java background so he/she will know better than I can tell). That makes the use of UML with PHP probably a less ideal choice, as the only achievement would be to create a set of "rules" that still need to be translated into code, which of course would make the process of building an application slower and more tedious. While to me, it is still not a big problem, as I personally see the advantages of what he/she calls a "bird view" regardless of whether you have to translate that view into code yourself or you use a tool to get it generated for you (and as a matter of fact, I still enjoy coding myself that much that I would probably follow the same steps working with another language), for others it may be an issue.

    Having said that, and hoping thus the original poster doesn't mind, I'll get once again into the discussion Agile Design vs. the traditional conception.

    I appreciate by the way the links 33degrees has posted, although obviously I've been there before. Not that I did probably grasp every aspect, but I did read many of the papers Fowler has made us available. Eventhough I am a fierce criticus of about everything in this life, I do recognize Fowler's authority in many fields. By the way, you do realise that "Is Design Dead?" is a question and not a statement, don't you? (no pun intended)

    The thing is though that the discussion whether UML has a place (and with it up-front design) or not, IMHO, is a rather philosophical one. This of course makes very difficult to achieve any consense in this regards, because we enter the field of believing and there are arguments for just about any variation in the theoretical conception of the subject.

    I understand for instance what BerislavLopac is telling me, but still have big troubles to cope with his view. Even after a good night sleep . I'll explain later where I think our different points of view differ.

    To me, design is indeed the phase of the project of planning in the most abstract way how the application and its different components rely to each other, without going too much into the details. This is of course a very fine line and in fact it can become even nasty to just drop one. Nevertheless, and having a little arquitectural/engineering background myself (high school), I tend to compare this phase with what in Arquitecture would be the phase of thinking and drawing in paper (nowadays using CAD software mainly). Once this phase is achieved, and the client satisfied (for so far that can happen), I'd go into the implementation phase. In arquitectural terms that would mean indeed starting the physical building process, i.e. laying bricks, while in software development that would translate into programming or producing code; whether this is final source code or not it's for me at this point not relevant.

    Yesterday, after having discussed for a while, mainly with lastcraft, I realised we were talking about very different circumstances. My job is mainly "reduced" to produce from simple CMS applications to E-commerce solutions. These are very well known and explored scenarios where the constraints are mostly well defined. The arquitecture keeps repeating itself and you clearly can take advantage of this fact. After having build an n number of applications you end up having a very clear view of what the problems you may be facing are, and therefore there is an advantage of trying to model the arquitecture as a whole, leaving only the details out of it, which will make every project different. Furthermore, I work on the LAMP stack, meaning I have a very specific scenario I will be working on.

    In lastcraft's case, as I have understood, it is a whole different ball game all together. The company he's working for serves very different kinds of clients with very different problems to be solved. As a result, it gets pretty difficult, if not impossible, to lay down a generic approach on how projects have to be carried out and thought off, which makes Agile Development the right approach for the job, as it is easier through Agile methods to deal with ad hoc decisions.

    Another important difference in the constraints we have to deal with is the number of developers involved in the realisation of a project. While it may make sense in some cases to work in pairs, as XP dictates, not all the companies will have enough employees available to make it possible, which obviously reduces the chances to choose for such an approach.

    In conclusion, I guess what I'm trying to get at is that, although we all have some common battleground (Web Development & PHP), strategies may vary much depending on the different situations, which makes no approach better, worse, more or less valid than others, but just different. For instance, for BerislavLopac, choosing whether to use a while loop against a do ... while loop is still a design decision, while to me it is an implementation detail. I still think that is a rather philosophical point of view.

    Once again, my excuses for the extended dissertation, my Spanish stubbornness, and for the fact that I won't probably be able to keep discussing this subject; Sunday or not, I must still get to work. Wish everyone a nice day.
    There’s more than one way to skin a cat.

  11. #61
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @nacho: fwiw, there are several tools that create/consume UML and target PHP code generation. Umbrello ( http://uml.sourceforge.net/index.php ) is one.

    I also liked the point you made. I sometimes feel that "aggressive" (in the sense of fluid) methods are very useful for discovering successful patterns for a particular problem domain (ie: vertical niches) -- and consequently produce good toolsets that fit those areas of concerns. Of course, this is "interesting" work because it involves a lot of creative aspects (pattern recognition=>refactoring loops, experimentation=>testing feedback loops, etc).

    Yet if the mandate is to repeat solutions often and predictably for a particular domain I guess your goal would be to start with such well defined toolset/patterns and use them in a regular cookie-cutter approach. In other words, I think traditional methods begin to have appeal once they can employ proven patterns and tools (probably vetted these days using "modern" development ideas) as a given.

    Still, something is unsatisfying to me about that. I can't put my finger on it. Maybe it is because even though I rely on stable toolsets, I really have much more fun trying to improve them

    Greetings.

  12. #62
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by nacho
    in PHP there is no tool to automatically generate code from UML schemas, while in Java you do have several tools to achieve that.
    Nonsense. Umbrello (as jayboots mentioned), ArgoUML, Poseidon and Sparx Enterprise Architect all create basic PHP code and stubs from UML.

    Quote Originally Posted by nacho
    To me, design is indeed the phase of the project of planning in the most abstract way how the application and its different components rely to each other, without going too much into the details. This is of course a very fine line and in fact it can become even nasty to just drop one. Nevertheless, and having a little arquitectural/engineering background myself (high school), I tend to compare this phase with what in Arquitecture would be the phase of thinking and drawing in paper (nowadays using CAD software mainly). Once this phase is achieved, and the client satisfied (for so far that can happen), I'd go into the implementation phase. In arquitectural terms that would mean indeed starting the physical building process, i.e. laying bricks, while in software development that would translate into programming or producing code; whether this is final source code or not it's for me at this point not relevant.
    You're still missing an important step in architecture, which is performed between the initial design and client's approval on one side and the actual construction on the other. Before a construction beguns, there is engineering work to produce all the calculations and plans and documents (e.g. blueprint) which will be used in the construction; this is the equivalent of programming.

  13. #63
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    @nacho: fwiw, there are several tools that create/consume UML and target PHP code generation.
    I obviously didn't know about it, so thanks for pointing that out.

    There is indeed IMHO an advantage to be taken from the fact of working often with the same arquitecture. Design patterns come from that fact. When you are doing the same thing all over again you realise there are certain aspects you could extrapolate and theorize in order to simplify things. Then again, I think dogmas are a dangerous thing.

    Quote Originally Posted by BerislavLopac
    Nonsense. Umbrello (as jayboots mentioned), ArgoUML, Poseidon and Sparx Enterprise Architect all create basic PHP code and stubs from UML.
    I don't think you're making me any justice with your comment at all ... I said:
    Quote Originally Posted by myself
    The main practical difference, as I see it, and of course, as many times before I could have it all wrong ...
    I don't know if I could have been any humbler ... but in any case it looks that it wasn't enough for you. Anyway, thanks for the additional information.

    Quote Originally Posted by BerislavLopac
    You're still missing an important step in architecture, which is performed between the initial design and client's approval on one side and the actual construction on the other. Before a construction beguns, there is engineering work to produce all the calculations and plans and documents (e.g. blueprint) which will be used in the construction; this is the equivalent of programming.
    I didn't miss anything, I just skipped it. I wasn't trying to make a white paper, just give my opinion based on my own experience. I mentioned before that I use a "baked" core framework to build web applications, and that would be my blueprint. It is indeed programming work, but I don't tell it as a per project duty because it is already done. All calculations are made beforehand. As I said, I work on the LAMP stack and the framework is based on it. The policy we have is to offer to the client what we already have. Developing in the sense of adding features or modifying the core framework is in my case an internal process and it is not billed to any particular client as such.
    I guess you could probably compare it to building prefabricated buildings. The only thing I need to know is how many rooms the client wishes to have, or if they prefer a lift instead of a staircase ... that kind of things.
    There’s more than one way to skin a cat.

  14. #64
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by nacho
    I don't think you're making me any justice with your comment at all ... I said:
    I don't know if I could have been any humbler ... but in any case it looks that it wasn't enough for you. Anyway, thanks for the additional information.
    You're right, the "nonsense" response was too strong and uncalled for. I apologize.

    I didn't miss anything, I just skipped it.
    Very well then. Have a nice day.

  15. #65
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by nacho
    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.
    There's something more to this. Beyond comprehending something complex, it's about the fact that you can build flexibility into a system, but there are different kinds of flexibility, and in practice you can't have all of them. You have to make a choice about what to decouple. And in order to know what flexibility to have, you need to be able to guess future requirements. With experience, it's possible to do that, but only to a very limited extent. I'll build some flexibility in, but it has to be cheap. Adding serious complexitiy to achieve flexibility is likely to be counterproductive, because complexity make the system harder to understand and therefore harder to change.

    I'm not discounting the possibility that there may be geniuses who can work miracles in planning ahead for requirements, but I've never actually met one. Lots of people claim that it's possible, though.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  16. #66
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    There's something more to this. Beyond comprehending something complex, it's about the fact that you can build flexibility into a system, but there are different kinds of flexibility, and in practice you can't have all of them. You have to make a choice about what to decouple. And in order to know what flexibility to have, you need to be able to guess future requirements. With experience, it's possible to do that, but only to a very limited extent. I'll build some flexibility in, but it has to be cheap. Adding serious complexitiy to achieve flexibility is likely to be counterproductive, because complexity make the system harder to understand and therefore harder to change.
    As lastcraft puts it "there is an n-squared component".
    Quote Originally Posted by dagfinn
    I'm not discounting the possibility that there may be geniuses who can work miracles in planning ahead for requirements, but I've never actually met one. Lots of people claim that it's possible, though.
    For the record, I'm sure I'm not claiming at all to be one of those people but I do try my best. Maybe other's people best is 1,000 times my best, I wouldn't know. That's why I'd like to leave it open, that's why I think it is relative.
    There’s more than one way to skin a cat.

  17. #67
    SitePoint Wizard drhowarddrfine's Avatar
    Join Date
    Aug 2005
    Posts
    3,438
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The second post by kyberfabrikken hit the nail on the head.

  18. #68
    SitePoint Wizard drhowarddrfine's Avatar
    Join Date
    Aug 2005
    Posts
    3,438
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That's why I'd like to leave it open, that's why I think it is relative.
    HEY! Let's leave my relatives out of this.

  19. #69
    SitePoint Evangelist
    Join Date
    Mar 2004
    Location
    Fort Lauderdale
    Posts
    522
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Thumbs up MVC Article continued...

    I would like to direct all to this article where Joe Stump talks about implementing a MVC solution for a php 5 project.

    The link to the article series is here:

    http://www.onlamp.com/pub/a/php/2005...mvc_intro.html

    I am curious as to the reason why he put this code in the class FR_Object

    Code:
    <?php
    
      require_once('Log.php');
    
      /**
      * FR_Object
      *
      * The base object class for most of the classes that we use in our framework.
      * Provides basic logging and set/get functionality.
      *
      * @author Joe Stump <joe@joestump.net>
      * @package Framework
      */
      abstract class FR_Object
      {
          /**
          * $log
          *
          * @var mixed $log Instance of PEAR Log 
          */
          protected $log;
    
          /**
          * $me
          *
          * @var mixed $me Instance of ReflectionClass
          */
          protected $me;
    
          /**
          * __construct
          * 
          * @author Joe Stump <joe@joestump.net>
          * @access public 
          */
          public function __construct()
          {
              $this->log = Log::factory('file',FR_LOG_FILE);
              $this->me = new ReflectionClass($this);
          }
    
          /**
          * setFrom
          *
          * @author Joe Stump <joe@joestump.net>
          * @access public
          * @param mixed $data Array of variables to assign to instance
          * @return void
          */
          public function setFrom($data)
          {
              if (is_array($data) && count($data)) {
                  $valid = get_class_vars(get_class($this));
                  foreach ($valid as $var => $val) {
                      if (isset($data[$var])) {
                          $this->$var = $data[$var];
                      }
                  }
              }
          }
    
          /**
          * toArray
          *
          * @author Joe Stump <joe@joestump.net>
          * @access public
          * @return mixed Array of member variables keyed by variable name
          */
          public function toArray()
          {
              $defaults = $this->me->getDefaultProperties();
              $return = array();
              foreach ($defaults as $var => $val) {
                  if ($this->$var instanceof FR_Object) {
                      $return[$var] = $this->$var->toArray();
                  } else {
                      $return[$var] = $this->$var;
                  }
              }
      
              return $return;
          }
    
          /**
          * __destruct
          *
          * @author Joe Stump <joe@joestump.net>
          * @access public
          * @return void
          */
          public function __destruct()
          {
              if ($this->log instanceof Log) {
                  $this->log->close();
              }
          }
      }
    
    ?>
    I dont understand the toArray function. What is that used for?
    And what do you think of that article series?

  20. #70
    SitePoint Enthusiast
    Join Date
    May 2004
    Location
    Gainesville, Florida
    Posts
    54
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think advocates of agile programming just look at things on an old, "If it works" mentality that was/is a dirty habit made very popular by Visual Basic 5/6. It works for them but I wouldn't hire one of them for a private sector job with benefits.

  21. #71
    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 mikehowell
    I think advocates of agile programming just look at things on an old, "If it works" mentality that was/is a dirty habit made very popular by Visual Basic 5/6. It works for them but I wouldn't hire one of them for a private sector job with benefits.
    I guess everyone is entitled to their opinion, but this is so far off base it borders on irresponsible.

    An Agile developer doesn't think "If it works..." they think "I guarentee it works, because 50-60% of the code I write is unit tests and I can deploy with confidence that everything I write is doing what it is supposed to"

    Second, becuase of their close interaction with the customer, they are sure what they are deploying is what the customer wants and needs becuase the customer is writing the stories and prioritizing them.

    Last, because they have the safty harnes of the test suite, the have the ability to refactor and clean up the design on the code at will. This is an essential step in the agile methodologies because refactoring creates the flexible applications which allow you to respond quickly to the changing needs of your customer.

    The fact that the customer changes his mind is not a problem, it is the normal course of things. If you did a big design up front, spent too long coding, and then the customer spots flaws in the design, you are in trouble becuase of the development methodology you have chosen. If you have prioritized work with the customer, performed a quick iteration and put the application in front of the customer and they find things they want to change, it is just normal. New stories get created and get prioritized into the next iterations.

    It does not seem like you have done enough research on Agile development to have rendered the opinion you did.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  22. #72
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    The fact that the customer changes his mind is not a problem, it is the normal course of things.
    Maybe... But at times, it doesn't stop you from cursing the -BEEP- till the air turns blue


    If you did a big design up front, spent too long coding, and then the customer spots flaws in the design, you are in trouble becuase of the development methodology you have chosen.
    I'm not particularly agile myself, but doesn't it make common sense anyways, not to run too far ahead anyway, in regards to your project? I mean is that you just do the minimum, get it approved, and from there, continue onwards...

    That is what I do nowadays; Is that being agile? I don't know, as I don't see myself being agile. The issue I have is that when something is complete, and it has been complete for 3 months for example, the client comes back and asks for a major change at such a late date

    How would being agile help in that situation?

  23. #73
    SitePoint Enthusiast
    Join Date
    May 2004
    Location
    Gainesville, Florida
    Posts
    54
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    I guess everyone is entitled to their opinion, but this is so far off base it borders on irresponsible.

    An Agile developer doesn't think "If it works..." they think "I guarentee it works, because 50-60% of the code I write is unit tests and I can deploy with confidence that everything I write is doing what it is supposed to"

    Second, becuase of their close interaction with the customer, they are sure what they are deploying is what the customer wants and needs becuase the customer is writing the stories and prioritizing them.

    Last, because they have the safty harnes of the test suite, the have the ability to refactor and clean up the design on the code at will. This is an essential step in the agile methodologies because refactoring creates the flexible applications which allow you to respond quickly to the changing needs of your customer.

    The fact that the customer changes his mind is not a problem, it is the normal course of things. If you did a big design up front, spent too long coding, and then the customer spots flaws in the design, you are in trouble becuase of the development methodology you have chosen. If you have prioritized work with the customer, performed a quick iteration and put the application in front of the customer and they find things they want to change, it is just normal. New stories get created and get prioritized into the next iterations.

    It does not seem like you have done enough research on Agile development to have rendered the opinion you did.

    And I don't think you or anyone else can coin the best case scenario of a methodology agile when it clearly puts as much planning into negating or minimizing scope creap as the one the OP was discribing. Both best case scenario's involved a lot of effort into making a game plan succeed. Both have worst case scenarios and I would not hire the agile over an equally qualified turtle because agile has more chance more chaotic. Personally I think this is like an english major debating the merit of the almost pointless word, niche, with a philosophy student.

  24. #74
    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 mikehowell
    And I don't think you or anyone else can coin the best case scenario of a methodology agile when it clearly puts as much planning into negating or minimizing scope creap as the one the OP was discribing. Both best case scenario's involved a lot of effort into making a game plan succeed. Both have worst case scenarios and I would not hire the agile over an equally qualified turtle because agile has more chance more chaotic. Personally I think this is like an english major debating the merit of the almost pointless word, niche, with a philosophy student.
    Perhaps I am misunderstanding what you are trying to say, but your characterization of Agile methodologies has about as much merit as if I said "Anyone who uses UML will cause your project to fail miserably becuase they care more about artistic drawings and documentation than programming and getting the system to work". This statement clearly is not grounded in reality, and therefore does not merit much discussion.

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

  25. #75
    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 mikehowell
    I think advocates of agile programming just look at things on an old, "If it works" mentality that was/is a dirty habit made very popular by Visual Basic 5/6. It works for them but I wouldn't hire one of them for a private sector job with benefits.
    I've seen some ridiculous things on here but this is just stupid. Jason pretty much sums up everything that is wrong with this. Ignorance is a dangerous thing...don't criticise something you don't understand (your post is evidence enough that you don't really understand what agile development is all about).


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
  •