November 21, 2007 at 9:10 am
Scope Creep?
Maybe. I agree that you don't want to make a project more complicated than it needs to be. But the key here is "than it needs to be". I would say: "than it needs to be to make the user happy and fully meet his needs."
If, for example, the user specifically says that he wants to create a list of the top 10 and bottom 10 books, it is appropriate for us to think about what it would take to make that requirement really work. As I said before, having a list of the top 10 books without regard to genre is like, well, comparing a varchar to an int. Ewww.
While the idea of tracking the type/genre of the book is adding to the scope of the project, I would argue that it is at least a necessary thought experiment in order to really meet the needs of the project. Paraphrasing what I think Kris said: it is not a bad idea to get all the ideas out there to see where there are holes in the database design (which is the point of the discussion -- where are the problems with the design in order to meet the needs of the project?).
The planning part of designing a good database is not one we want to miss even for a small project. Certainly part of the planning would be to take a step back at some point and assess just how important each database element/application feature really is. But you can't weed out ideas that you haven't considered to begin with.
And while we certainly can add new features in the future without much problem, it doesn't hurt to do a little up-front thinking. Suppose we didn't think of the genre idea until Steve already had 200 books in his database? Is he really going to want to go back and enter genres for 200 books? No, he would thank us for having thought of it up-front so the data entry (entering as he goes) isn't painful.
November 21, 2007 at 9:13 am
I'd like to further note my concern that while many people are complaining about the lack of requirements, there are also a number who are not reading or understanding the ones that are there.
If anyone was unsure of what was required they have obviously forgotten the golden rule "If you are unsure, ask!"
The next most important rule, which also seems to have been forgotten: State your assumptions!
November 21, 2007 at 9:20 am
Matt Lacey (11/21/2007)
...If anyone was unsure of what was required they have obviously forgotten the golden rule "If you are unsure, ask!"
The next most important rule, which also seems to have been forgotten: State your assumptions!
Excuse my shouting.
Harald M.
November 21, 2007 at 9:46 am
jomobono (11/20/2007)
First off regarding requirements, this is a personal opinion, but here goes.Steve has provided ample requirements based on the scale of his project to prototype a preliminary system.
I say this because, although more requirements may be useful, something of this size does not need a large development team, nor does it need to go thru rigorous design testing, prior to implementation. Having said this I can comfortably state that the system specified will not be mission critical, and therefore can be implemented using alternate means to gather requirements.
There are times when speed, and/or budget constraints do not allow for full-blown requirements, analysis, and design phases. In those instances prototyping and asking specific questions help you gather the additional information needed to develop and stabilize a design. There are also simple things that can be done within a design that will allow it to be extendable at a later date.
Couldn't disagree more. If a project is truly a "small scale" project, the requirements, analysis, and design will be likewise. I don't think anyone was saying to bring in a team of consultants for this project, but rather noting how the unstated requirements could affect the design decisions.
TroyK
November 21, 2007 at 9:59 am
I totally agree with jomobono. This project with only Steve's stated criteria, and with his original design could be rolled out by 1 person in 1 day. Any design changes shouldn't extend it beyond that, at least not much beyond it.
It's probably almost more worth doing it first and then asking questions.
Tom Garth
November 21, 2007 at 10:04 am
cs_troyk (11/21/2007)
jomobono (11/20/2007)
Couldn't disagree more.
tgarth (11/21/2007)
I totally agree with jomobono.
I have to laugh! :hehe:
Ryan Randall
Solutions are easy. Understanding the problem, now, that's the hard part.
November 21, 2007 at 10:16 am
Ryan Randall
Solutions are easy. Understanding the problem, now, that's the hard part.
I like that.
November 21, 2007 at 10:58 am
I'll take us in a slightly different direction.
1. Based on the decription of the project (a casual collection of personal book reviews), why are you bothering with a database? I'd consider a blog - you may want a bit of structure, but frankly "grep" is about all you need for a search engine.
2. I don't like the ISBN as the key. You eliminate books that went out of print before 1966 with that decision.
I think of it because my 1941 Plymouth breaks every database with a VIN number constraint. VIN numbers were invented in 1979. Luckily, DMVs were some of the earliest adoptors of databases, so they know this and the constraint is based on YOM.
I'm not sure what you do with books. I could ask my dad - who knows his way around databases and is now a rare book dealer, but he will probably just send me back to Item One "I wouldn't bother putting it in a database".
I have my own issues like this - cataloging "ethnic" 78 RPM recordings. Over structuring it will get you - it makes the accounting systems I program to make my living seem so simple by comparison.
I see some of the other issues, but we'd have to get past these two for there to be any revelance to the others.
Roger L Reid
November 21, 2007 at 11:09 am
R L Reid
I'll take us in a slightly different direction.
...and just when we had it all figured out, we were told that our reasoning had no depth.
Tom Garth
November 21, 2007 at 11:20 am
R L Reid wrote (11/21/2007)
...Based on the description of the project (a casual collection of personal book reviews), why are you bothering with a database?...
That wasn't the only description we got. We were also told that the user wants to have various reports listing books by author, ranking, etc.. The devil is in the details, not the 30 second sound-bite initially proposing the project.
I totally agree that the first step is to consider if a database is even relevant. That's the first question I ask myself when presented with a new project proposal. I'm glad you wrote your posting. However, I disagree that the description of this project indicates that a database isn't appropriate.
November 21, 2007 at 1:27 pm
http://bloggingabout.net/blogs/dennis/file/projectswing.jpg
Best Regards,
Chris Büttner
November 21, 2007 at 6:34 pm
cs_troyk (11/21/2007)
jomobono (11/20/2007)
First off regarding requirements, this is a personal opinion, but here goes.Steve has provided ample requirements based on the scale of his project to prototype a preliminary system.
I say this because, although more requirements may be useful, something of this size does not need a large development team, nor does it need to go thru rigorous design testing, prior to implementation. Having said this I can comfortably state that the system specified will not be mission critical, and therefore can be implemented using alternate means to gather requirements.
There are times when speed, and/or budget constraints do not allow for full-blown requirements, analysis, and design phases. In those instances prototyping and asking specific questions help you gather the additional information needed to develop and stabilize a design. There are also simple things that can be done within a design that will allow it to be extendable at a later date.
Couldn't disagree more. If a project is truly a "small scale" project, the requirements, analysis, and design will be likewise. I don't think anyone was saying to bring in a team of consultants for this project, but rather noting how the unstated requirements could affect the design decisions.
TroyK
If you read it carefully, I am not doing away with requirements, analysis or design, simply using an alternate method of gathering and utilizing those requirements.
There should be differences in approach which correlate with scale of a project. For example would you use the same processes to remodel your kitchen that a large construction firm uses to build a high rise building? What would happen to your costs if you decided to use those methods?
This does not mean that fundamentally you will not be going thru many of the same steps, just that the type and level of information needed up front or throughout the process is very different.
In a small project a contractor would most likely sketch out the layout and take you to a showroom to have you decide what you like, and then transfer the information gathered to a CAD program of some sort.
In a large high rise building an architectural and engineering team is taking into consideration many more factors like, soil test results, weather conditions for the area, fault lines, just to name a few things before they even beginning to determine which structural design is best suited for the building in question.
Perhaps remodeling the kitchen needs all these tests too, simply to maintain a uniform approach between construction projects 😀
Also if you noticed I only laid out a structure and started asking questions, much the same way a contractor sitting at your kitchen table would start sketching while asking you questions about how you would like things to be laid out. Showing you the sketch will give you more ideas, placing it into a 3d-modeler will give you even more ideas. Taking you to various showrooms will solidify what you really want.
Also I didn't not tackle database performance ... which would be like trying to determine energy requirements before determine what will go into the kitchen. Energy efficient appliances would be an added feature and normally not crucial to the the lay out or scope of the project. Same with cosmetics such as color or material types, which would be like determining what the field names should be or what the GUI will look like.
First step determine layout or scope 🙂 Scope creep does not exist if you find out up front what the customer wants and interact with them through out the development lifecycle. However, scope creep does occur if you try to enforce your own ideas onto the customer and tell them this is what they will get based on requirements provided.
Too often I have heard the phrase "but that was not in the original requirements", and usually from the very same people that at the start of a project lamented that there were not enough requirements, and proceeded to spend the next 8 months gathering and analyzing requirement before writing a single line of code. To top it off they then complained of scope creep.
Unfortunately though if you really analyze what happened it was lack of communication with the customer, and a team trying to enforce there own ideas onto a project. It's good to give more or to offer more to a customer before starting or even during development if additional functionality or features are discovered. Don't be afraid to ask the questions that will add features or functionality to a product. Doing so you will get you much more information from the customer and will provide you with a much more stable product in the end.
Asking questions that expand scope up front does not equal scope creep it ensures boundaries and makes them explicit.
For example the question "will you be storing reviews written by others in this database"? Although Steve stated he will be the only user and the database is for his own reviews; there is room for expansion here.
A "No" answer would define this boundary, and we would know that some thought has been put to the question. We still design with the ability to add a reviewers table in mind, but we know this is not needed for now. If the answers is "Yes" then we go ahead and add the reviewers table at this point. This is not scope creep, failing to ask the question, and then telling Steve towards the end of the project that a reviewers table was not part of the original requirement, is a failure on the analyst, designer, and developer's part, not Steve. Steve did not fail to give us the requirement, we failed to ask if it would be needed 😀
It is our job to ask the questions in the discovery process, not the other way around. For me prototyping is like taking the customer to a showroom where they can touch and feel a final product that will be very similar to what will be delivered to them as the end product. Sometimes that extra visualization helps define things much faster and much more accurately. It also tells the customer you are working on their project. Also, asking questions that provides them with additional features or future functionality tells them you have their interest in mind, which usually translates to more sales in the future or income for me;)
just my humble opinion
November 21, 2007 at 7:36 pm
jomobono (11/21/2007)
Maybe you could write a book on it jomobono 😀
The kitchen analogy is a good one to illustrate another point. Often what the customers wants will be established (using various techniques), and kitchen will get built accordingly. The customer will then come to start using it, and then they realise there's no fridge!
How did this happen? Who is to blame? :angry:
Well, I think this is down to a lack of business analysis. Questions should be asked about why the customer wants a kitchen. What are they going to use it for? To prepare a meal? Great! What's the process you go through to do that? Buy food, store food, prepare food, throw packaging away, cook food, put food on plate, etc.
I think this step is often missed because the customer thinks he knows exactly what he wants and doesn't want to "waste" time and money going over what he already knows. That's a shame, because it's the easiest part for the customer to talk about (because it's an area he's a specialist in), and it can make the rest of the project so much easier (and faster and cheaper) for everyone involved.
After all, you might end up figuring out that he actually wants a whole house. :crazy:
Ryan Randall
Solutions are easy. Understanding the problem, now, that's the hard part.
November 21, 2007 at 7:43 pm
jomobono (11/21/2007)
cs_troyk (11/21/2007)
jomobono (11/20/2007)
First off regarding requirements, this is a personal opinion, but here goes.Steve has provided ample requirements based on the scale of his project to prototype a preliminary system.
I say this because, although more requirements may be useful, something of this size does not need a large development team, nor does it need to go thru rigorous design testing, prior to implementation. Having said this I can comfortably state that the system specified will not be mission critical, and therefore can be implemented using alternate means to gather requirements.
There are times when speed, and/or budget constraints do not allow for full-blown requirements, analysis, and design phases. In those instances prototyping and asking specific questions help you gather the additional information needed to develop and stabilize a design. There are also simple things that can be done within a design that will allow it to be extendable at a later date.
Couldn't disagree more. If a project is truly a "small scale" project, the requirements, analysis, and design will be likewise. I don't think anyone was saying to bring in a team of consultants for this project, but rather noting how the unstated requirements could affect the design decisions.
TroyK
-- snip good analogy --
just my humble opinion
I agree that iterating over prototypes can be a good way to get requirements. I'll chalk this up to a misunderstanding of what you meant by "...ample requirements...", "...preliminary system...", and "...full-blown requirements, analysis, and design phases."
This is NOT to say, however, that I agree with approaches that advocate "throwing things against the wall to see what sticks" and modifying from there until you get it right (which is my perception of some "agile" processes). I prefer to spend some time thinking about the problem up front (perhaps moreso than "agilists" are comfortable with) and working the design phase with a full understanding of what's informing the design tradeoffs that need to be made - it has always payed huge dividends for me.
TroyK
November 22, 2007 at 8:45 am
Congrats Steve. A terrific discussion, especially the most recent part of it.
When it's all done, perhaps you could get people talking about time estimates. There's an issue I often have problems with.
Tom Garth
Viewing 15 posts - 76 through 90 (of 96 total)
You must be logged in to reply to this topic. Login to reply
