|
Shog9 wrote: If you were talking to a gung-ho Agiler
of course the real test is how many people notices the difference in the same paragraph between "agile" and "Agile".
I program agile, not Agile, because my business is agile; now I could have done Agile, but that wouldn't be as agile in an agile developement, because Agile isn't agile enough for truly agile environments. BTW, anyone feel free to quote me to your professor if you don't mind him assigning you extra revenge work. 
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
|
|
|
|
|
El Corazon wrote: I program agile
Do you do stretching exercises first?
Jon
Smith & Wesson: The original point and click interface
|
|
|
|
|
stretch for coffee... stretch for login to CP... yup!
|
|
|
|
|
Shog9 wrote: the only thing that's consistent is that none of them are a panacea for producing a quality product on-time and under-budget
Exactly. I think some of these terms were really geared to non-technical managers who have a clouded illusion that having a quality product and coming in under budget and on time is a possible feat.
In my 15+ years of programming/developing, I have never heard of a high quality product be on time and under budget together.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
Basically, it boils down to this, Vista is the birth of a new version of Windows. Natal, as you may know, refers to a birth. Increment means go to the next. So Incremenatal Programming is done for Vista, while we continue to use XP for Windows XP. Good luck on the exam.
Jon
Smith & Wesson: The original point and click interface
|
|
|
|
|
Julia - I'm going to give you one piece of advice here. Stop thinking of methodologies as discrete items that actually mean much. Frequently, these methodologies are just subtle variations of another methodology, with new terminology thrown in to hide the fact that there's not much new in there at all. In my company, we don't practice methodologies. We design and develop software using the quickest methods we can that include full documentation and development consultation. Blind adherence to methodologies tends to get in the way of actually delivering software.
|
|
|
|
|
Dude 
Julia4u wrote: No google is not helping me out.
led mike
|
|
|
|
|
led mike wrote: Dude
Julia4u wrote:
No google is not helping me out.
It depends what she was putting in. If she wanted information about incremental versus iterative development and put in "nice red shoes" then she was never going to get help.
|
|
|
|
|
Pete O'Hanlon wrote: It depends what she was putting in
Yes, obviously she can't figure out to put in the same words she put into her post here. That was my point. 
It seems to me that anyone wanting to know anything about Agile and has not yet found Amblers site just isn't looking.
led mike
|
|
|
|
|
Hell - even Wikipedia has an article or two.
|
|
|
|
|
Hi Everyone,
So I'm stumbling my way through trying to design a system that I'm working on, and I realized that just as there are patterns that are often talked about in OO design there appears to be common questions asked when thinking through and validating the design.
At this point, I'm not exactly sure what they all are, but it seems I'm asking the same questions over and over in order to make sure my design works.
So... what questions do you ask yourself when reviewing a design?
|
|
|
|
|
I generally ask questions like:
What problem is this attempting to solve?
Does it solve it?
What other ways could this be done?
Are they easier or a better fit?
Is it necessary, or are we just adding fluff?
Is this maintainable?
And the questions to ask at the end:
What's missing?
How do we accept this (what are the acceptance criteria)?
|
|
|
|
|
Pete O'Hanlon wrote: I generally ask questions like:
What problem is this attempting to solve?
Does it solve it?
What other ways could this be done?
Are they easier or a better fit?
Is it necessary, or are we just adding fluff?
Is this maintainable?
And the questions to ask at the end:
What's missing?
How do we accept this (what are the acceptance criteria)?
And the question after the question at the end:
What's for lunch?
|
|
|
|
|
Along the lines of what Pete posted you can look at the Agile and RUP[^] analysis to see those and more considerations along with suggested timing of when questions need to be asked and asked again. Be sure to check out the links in that page, it's just a starting point.
led mike
|
|
|
|
|
Does it satisfy the requirements of a good user interface (assuming it ultimately leads to software someone uses and not a machine or other software).
I tend to think about the requirements and the user experience first, even mock up a UI on paper. Try to eliminate as much work or complexity on the part of the user as possible so that the user can focus on accomplishing *tasks* rather than manipulating data.
Once I have that decided the rest is easy because it simply has to meet the criteria of satisfying the task oriented design decisions.
If you start from the bottom up on the other hand then you are faced with uncertainty at every level and ultimately could end up with a very computer programmer oriented design but not a user friendly design. (i.e. the end user get's exposed too much to the inner workings of tables and databases and how the computer and software works instead of simply being able to view it as a machine that helps them accomplish the tasks they already know and understand).
This is the essential pivot point between what users percieve as "good" software and what users perceive as "bad" software.
"The pursuit of excellence is less profitable than the pursuit of bigness, but it can be more satisfying."
- David Ogilvy
|
|
|
|
|
I was just commenting on this[^] article, and said:
"My general rule is that design should be top-down, but implementation should be bottom-up."
Has anyone else come to this conclusion?
Or have reasons not to do it that way?
|
|
|
|
|
There is no cookie cutter rule or process or whatever that I can tell. The needs vary from project to project and even more so from company to company. If there is anything close to a cookie cutter map of project activities it would be this one.[^]
PIEBALDconsult wrote: My general rule is that design should be top-down
That doesn't really work with large systems having a relational database back end which is very common. Starting with the model and designing off of that for the different sub systems of the system is normally the way it works.
led mike
|
|
|
|
|
led mike wrote: Starting with the model and designing
That would seem to imply that you've already begun implementation -- creating the database.
Ideally, one of the last steps of design would be defining the database schema, then the first step of implementation would be creating the database and work up from there.
In many cases (including my current project), this can't really be achieved because the system accesses third-party databases, but there may still be the need to define views and such. This is true of any off-the-shelf product to which one must interface.
|
|
|
|
|
First I reiterate, my example is for a large business application. This means different project types could vary greatly from what I am saying.
PIEBALDconsult wrote: That would seem to imply that you've already begun implementation -- creating the database.
No, you start by modeling (design phase) the model. So..
PIEBALDconsult wrote: Ideally, one of the last steps of design would be defining the database schema,
Yes, I am saying from my experience one of the first things you do is model/design your model and part or all of that can end up being implemented in one or more database schemas.
led mike
|
|
|
|
|
PIEBALDconsult wrote: "My general rule is that design should be top-down, but implementation should be bottom-up."
I've ran into something similar in my own experience--I've come up with some pretty good solutions when the design specifications were done from the top down, and when the implementation was done from the bottom-up to meet those specifications. Generally, I don't introduce any patterns or any preconceived architecture until I can get the simplest prototype up and running (using standard structural programming techniques) and then refactor it and generalize it at various points until a design emerges.
It works for me in most cases, but the trade off in this case is that this approach assumes that you can pretty much refactor your way out of anything--and this might not be the best way to do things if you have a team that doesn't have much experience in refactoring. Without refactoring, the approach I mentioned above will quickly descend into a "Code & Fix" scenario, so overall, I would recommend it if you can guarantee that you can keep your code base relatively clean..
|
|
|
|
|
I don't know the meaning of "refactoring".
No, seriously, I have to find a definition of "refactoring".
Chances are, I do it, but I just don't know it.
|
|
|
|
|
|
Yes, I've come to the same conclusion over the years. In fact I've come to believe in a form a form of 'undirected' development sometimes known as z-programming. The concept is that you keep a proportion of your team busy all the time coding from the bottom up without any particular spec or goal, simply taking the existing set of low level facilities, be that APIs or COM objects or graphics primitives and combining in ways that seem like they might be useful, creating data structures and containers and algorithms that conform to best practices but don't have any particular application in mind. You do your design from the top down and create at least one empty shell style prototype which consists mostly of the UI of the product and any product specific novelties. Application development then becomes a process of filling in the functionality using the generic tools you've developed. One of the key things being no-one is allowed to reinvent for a specific app anything that's already available in the codebase for generic usage. You soon find if there's an area your z-programmers have been ignoring and they can be directed to concentrate on it. This does a number of things, it keeps programmer busy, it makes them write truly generic code, it allows them to concentrate on what they're good at and to be creative, it ensures that re-use ( a goal but seldom a reality ) actually happens.
This is all great for desktop application but if and how it might be applied to web based applications is still amystery to me 
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Matthew Faithfull wrote: z-programming
Huh, I hadn't heard of that. I do some, but I didn't know it was a "good thing".
|
|
|
|
|
The link is now dead but if I get the drift of what's being discussed I have to say design should *ALWAYS* be from the top down.
(One point I need to make that I come from the background of a small company that designs, builds and sells software globally, we don't have teams to do this or that, there are very few of us and we each do everything, no one is a specialist "designer" or strictly a "coder".)
Designs that are bottom up are noticeable (for all the wrong reasons) in an instant because they focus on how the computer works, not how the user thinks. A user thinks about tasks they want to accomplish, a programmer thinks about how the computer will process information.
If the programmer is let loose to do the design and they are a rookie with little exposure to real world feedback on their design they will often and naturally think about the data first going bottom up, it seems natural to start at the bottom (the stuff they know best) and work their way up to the real world application (probably the stuff they are the least comfortable with).
After some real world seasoning and feedback (and most important of all time on the support queue) hopefully they will start to think about the tasks the user needs to accomplish in the fewest steps and simplest method to get the user there with no thought at all to how it will be implemented during design, mock up a UI because it helps even on paper, run it past non programmers etc.
Only then start thinking about implementation with the goal of satisfying the task oriented design.
As far as implementing it, I don't know if it matters that much as long as the goals are satisfied.
I prefer a "literary" implementation, neither top down or bottom up. Working on a huge project with a small team can be overwhelming, it's easier to work on rough details and refine later.
I plot out rough outlines on paper first, like chapter headings, code those items first so I have everything covered but not fully implemented, then go in and refine each one, perhaps adding "section headings" for each "chapter", filling in the bits between the chapters. In this way you always have a mental feeling that you have the whole project covered and the rest is just refinements. It becomes far less overwhelming and seems more like bite sized chunks.
For example let's say I have a large project with hundreds of business objects, I would create all the objects first without any real code implementation, look it over think about the design, make changes as necessary, try to get it as quickly as possible to the point where I can roughly make a real interface to try out the workflow, then go in and fill in all the CRUD methods (create, read, update, delete), then go back in and add business rules or further refinements.
Of course this is often based on a data access layer that I've already developed some time ago so I guess in a sense if you are starting from nothing then you do need to do a little bottom up first but you can't simply go in a straight line from bottom to top. (Unless it's been planned far *too* much and too detailed to begin with. Always a bad mistake to make, some looseness is required.)
"The pursuit of excellence is less profitable than the pursuit of bigness, but it can be more satisfying."
- David Ogilvy
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
