October 6, 2010 at 12:32 pm
<<Since 2006 Honda has made all the engines in all 33 cars of every Indy race, so no matter who wins, Honda wins.>>
Just curious, but for the sake of a logic twist in this conversation. . .if the above statement is true, isn't it equally true that "no matter who loses, Honda loses"? 🙂
October 6, 2010 at 1:18 pm
I think the analogy is completely flawed.
If you want a true analogy, it would be between the process used to design and develop the engines and the software development process. I think you would find that the engine development process is probably just as messy as the software development process, and that the Honda engineers would not let adherence to some half-formed methodology get in the way of getting the job done right.
October 6, 2010 at 1:29 pm
Very incorrect, and I can say for sure you have done no research or investigation into engineering development methods at Japanese automakers.
October 6, 2010 at 1:43 pm
kenambrose (10/6/2010)
Very incorrect, and I can say for sure you have done no research or investigation into engineering development methods at Japanese automakers.
So, you are saying Honda engineers would let adherence to some half-formed methodology get in the way of getting the job done right?
October 6, 2010 at 1:48 pm
Umm, do some research and you can answer your own question.
October 6, 2010 at 2:12 pm
kenambrose (10/6/2010)
Umm, do some research and you can answer your own question.
You are the one saying I was "Very incorrect". If you can't backup your statement, I guess there is nothing to talk about.
October 6, 2010 at 3:27 pm
Umm, you are not worth the time, sorry.
October 6, 2010 at 3:32 pm
To hose down the inbound flame war:
Regardless of how the R&D department at Honda works, the point is that the engine is a finished product, then reproduced.
The equivalent of a vendor's final development, and is shipping a software product to clients. Every honda engine is not built from the same set of base specs to mimic the now beautiful Indy500 engine, but it does have pistons, spark plugs, etc. It's the equivalent of our tables, procs, and the like.
If we perfect a DB, sure, we'll distribute it to do that job. Reaching that point is not necessarily the product of completely standardizing the entire build process.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
October 6, 2010 at 3:51 pm
Having different specifications for a finished deliverable does not mean the methods one uses to implement the deliverable have to be different.
I worked for years in custom manufacturing industry. Almost every job, even for the same client over time, had custom specifications.
But we used the same management, production, and control methods to produce the finished product.
I think you may be confusing methods with specs.
ken
October 6, 2010 at 4:09 pm
kenambrose (10/6/2010)
Having different specifications for a finished deliverable does not mean the methods one uses to implement the deliverable have to be different.I worked for years in custom manufacturing industry. Almost every job, even for the same client over time, had custom specifications.
But we used the same management, production, and control methods to produce the finished product.
I think you may be confusing methods with specs.
I could see how that would be a conclusion, but I don't believe I am. It's also possible that I see DB'ing as more complex because I don't tend to work on the cookie cutter jobs. The custom specs, especially from a DB side, tend to interfere more with the basic methodology.
Where in one case a natural key exists and makes sense, in another while existing, it isn't feasible because you need a better methodology to speed up query logic. While the generic CRUD might be acceptable here, in another case you may need to build in logic controls because you're using a multi-table master so you can't enforce via Foreign Key.
The Custom specs drive a lot more of the base development of a DB engine than a car engine, especially when it comes to tuning and performance.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
October 6, 2010 at 6:31 pm
"I think the article would have been much more effective had it just focused on the product rather than negatively portray people who are trying to do their job diligently."
Actually I think it's very important to get the schema right. The behavior I was criticizing is where database designers and DBAs spend all their time thinking and making significant variations at the single-table level and little or no time thinking of the consequences of the inconsistencies they are probably introducing into both the database and the application.
October 6, 2010 at 6:50 pm
andycao (10/6/2010)
That's how I saw it. Gosh, an ad disguised as a SQL Server Central article. OK, moving on...
I thought I'd explain my position here (as the author). I am a software consultant and the company web site on which Rapid Application Prototype is posted is my company's web site. There is of course the possibility that publishing this article could lead my company to do some business that it would not otherwise have done. But that's about it for financial benefit. If RAP were a product for sale, it would have a price tag.
This article would be pretty pointless if I did not distribute sofware that actually does what the article talks about. Without the software, it'd be just another pleasant-sounding vague idea.
The software is distributed free of charge. I long ago gave up on the idea of selling both the concept and the software after trying it out on folks and realizing how few of them had any idea what I am talking about. My response from most people is a polite "that's nice" and then they move on.
My personal benefit in publishing this article is that I am hoping to find the handful of people who have an interest in process improvement and who believe that the way we do things now is incredibly sub-optimal. I don't know what would come of my association with such people, but nonetheless I would dearly love to meet them. I suspect there are very few of them, and without an article series like this one my odds of finding them (or them finding me) would be almost nil.
October 6, 2010 at 7:02 pm
bienvenunet (10/6/2010)
Question: Can RAP and the concepts that the series will discuss be used to develop Web Parts and features for SharePoint?
I have no experience with coding SharePoint and so unfortunately cannot answer this question directly. However I can give you some guidelines that might allow YOU to answer the question.
RAP requires that you build the whole database using RAP's design methods. Your app's database can of course interface to other databases and you can store foreign keys to other databases' tables inside of RAP tables, but RAP's ability to interact with other data ends at the boundaries of its own tables.
If SharePoint is similar to, say, Microsoft's Enterprise Library logging and authentication features, where the Microsoft-supplied part of your app is stored in its own separate SQL Server database (and you connect the various databases via your app) then a RAP-based application can work with SharePoint. However if you are required to mix your schema in with SharePoint tables in the same database, then the usability of RAP is doubtful.
October 6, 2010 at 7:19 pm
C. Grant Anderson (10/6/2010)
A lot of talk about relative points and yes it does really look like a promotional ad. After skimming the website and related white paper the big questions in my mind are:1. Has anyone tried using this and can give us an objective evaluation about how useful this really is in the real world? The software world is full of a lot of claims and oft times they sound like a good idea but do they really deliver the automation of software development? How is it with this product?
2. There's a supposition here that the database design is complete and perfectly in 4NF. That's a very big supposition. In app development no database is ever fully complete. So what happens in this product when the underlyng database must change? How does this product/approach handle the necessary changes? Easily? Poorly? This is real world effect that is critical.
3. There's not enough real world info in the article or the website's white paper to get a good overview of the approach nor is there is full instance of an app created and presented. So, is this just a middle tier automation approach that ignores the database as well as the GUI? It looks like a lot of work went into this, and a lot of work is required to set it up and get it running (having to create some definition files...say, can't it just read it directly from the DB?), but just how useful and practical is this in the real world situations? (This wraps back to my point #1).
Can someone who has tested this post their results and comments here?
Thanks.
- Grant
Grant: Sorry about the appearance of an ad. You might read my previous post on this subject. It's hard to distribute software to people without it looking like some sort of promotion.
The only people who have used RAP in actual application development are myself and people working for and with my company. I cannot show you real-world apps we developed using it because they are the internal property of my company's clients.
I am trying very hard to broaden the usage base of RAP. Unfortunately in order to make that happen I first have to make people aware of RAP before such a base exists. So it's a Catch-22 if I'm to be required to demonstrate an installed base before popularizing the concept.
With regards to the fact that schemas change ... yes they do and RAP handles this very well. In fact it handles change much better than hand-written apps do. Generally speaking when you change your schema, you must do it by altering existing tables (since you can't just recreate them due to the existing data, foreign key relations, etc.). The RAP code generators look right into the database and generate entirely new CRUD code and data-layer code from the schema that you actually have in there. So you can do all the ALTERs you want, then rerun the RAP generator and both your database CRUD and your data layer code will be automatically updated for you. And because of RAP's strict enforcement of multi-tier structure, your app will likely survive very nicely due to the absence of specialized hand-written hard-code that depended on the old schema.
And finally thank you for your assessment about the amount of work that went into this. Right now it's five years of evenings and weekends and counting.
October 6, 2010 at 7:27 pm
Roger L Reid (10/6/2010)
Another silver bullet for "what's wrong with software development".The rhetoric is familiar:
1. Assert such a problem exists - "every knows it", so no analysis needed
2. Make a flawed analogy with some other production process, without exploring its relevance.
3. Show the [Concept|Product], in its Blinding Simplicity, that once and for all will make software development Easy and Cheap.
There are no silver bullets.
Roger: I think the question here really is whether I have got something worth trying that really makes writing applications more efficient. I agree that there have been many "solutions" that really weren't very good because they can't be generalized, they cause more problems than they solve, etc. Maybe mine is one of them.
Then again there are true leaps in technology. Like when we went from machine code to assembly language, for example. Or from assembly language to compiled code. Or from procedural design to object-oriented design. Or from flat-files to relational databases, for that matter.
Silver bullets all.
Viewing 15 posts - 46 through 60 (of 84 total)
You must be logged in to reply to this topic. Login to reply