October 6, 2010 at 6:54 am
There is a product that is available, but it is free. This is not just an advertisement, in my opinion, but also a philosophy over how you ought to build an application, and design a database. Future articles will examine some of the consistency driven techniques used that you might want to incorporate into your own designs.
October 6, 2010 at 7:02 am
Holy One (10/6/2010)
There's a lot of beefing and complaining going on here, hearkening back to the early 20th century when doubtless the same complaints were heard about the Ford assembly line:1. This guy's gonna put us craftsmen/ex-bicyclemakers out of business
2. Yeah it's easy to make a black car on an assembly line but watch out when they ask him to make one in colour
3. This guy has some kind of hidden agenda; I don't care if this technique will save my company thousands of dollars -- I'm not going to be hooked.
All of which makes me think this guy's on to something....
1. Doubtful. There is always a place for craftsmen (Ferrari/Porsche/Customcars/"pimping" and so on)
2. Or just wait until they start recalling cars because of a flaw in the assembly line. So instead of a few cars... its ALL of them
3. They all scream that. Use <insert tech> and save money/time and create better/faster/more efficient code.
/T
October 6, 2010 at 7:03 am
I agree being consistent is a good thing - however, design and coding principles are also important:
Example:
I maintained a multi-tiered app which uses a business framework and has a business logic layer. In this app, every single screen that allowed you to edit an object followed the same principle...
Save - saves the changes or applies the edits if you are editing a child object, Cancel - cancels the changes and discards the object, or rolls back the changes if you are editing a child object
Of course, even though the same functionality was required and the same functionality appeared to be used, it turned out that every form was a copy/paste of the base class and didn't actually inherit from it. This meant that I had two choices -
- Apply the changes to all objects each time I make a change and hope that I don't miss any
- Modify all objects to inherit from the base class and then only make one change
Although the second method took a bit longer at first, the payoff was worth it. I made changes to the way the form has worked a few times to fine tune the logic, and now I've not had to touch it for a long time. Any new forms which require this functionality need one line modifying before they work 'out of the box'.
The principles of good design and understanding of the tools are way more important than which tools you use. It's still perfectly possible to mess up an application (that I have to fix!) using great tools - this being a perfect example.
October 6, 2010 at 7:06 am
The Indy 500 analogy is probably why I read the article, so I can't slam that, or the spirit of the article - sure standards make things better. I'm kind of lost on the author's perspective though. I don't know of any shop that doesn't work to or towards standards and I certainly don't know of any where the apps and db folks work in vacuums and do not collaborate with each other. Maybe that's the joy of smaller companies, I do both db and front-end work, as do most of the people I work with and we work on things collectively. My boss would sure love something that makes the learning curve less daunting for the "next" guy, but then I would as well as at some point I am very likely to be the new guy again. Kind of stating the obvious, but the author spent a lot or words likewise. I think the article should have focused on the product and concept and less on the homily. Just my 2 cents.
October 6, 2010 at 7:19 am
I think you are missing the point then if you think SQL Developers will be extinct. It seems to me that all "pushing the button" will do is eliminate the boring, repetitive work that you need to do (creating the basic procedures needed in any system) and give you the time you really need to be more creative, efficient and effective in how you solve the more complex problems of the system that is being built. I used a tool to do this for my developers and they loved it. It saved a lot time plus it provided a nice consistent framework for the procedures with all basic error trapping and comment blocks pre-built already. They could use it or modify it as needed.
October 6, 2010 at 7:28 am
jim7429 (10/6/2010)
The Indy 500 analogy is probably why I read the article, so I can't slam that, or the spirit of the article - sure standards make things better. I'm kind of lost on the author's perspective though. I don't know of any shop that doesn't work to or towards standards and I certainly don't know of any where the apps and db folks work in vacuums ....
The analogy caught me when I edited this one.
However you're lucky. I've worked in quite a few shops where the DBAs did their own thing, and ignored or did not communicate with developers. I've also seen many developers that threw tables together without thinking about design, or without understanding normality and what advantages it brings (or disadvantages). Too often I've seen inconsistent development in all kinds of applications, in-house and commercial.
October 6, 2010 at 7:30 am
scoia (10/6/2010)
I think you are missing the point then if you think SQL Developers will be extinct. It seems to me that all "pushing the button" will do is eliminate the boring, repetitive work that you need to do (creating the basic procedures needed in any system) and give you the time you really need to be more creative, efficient and effective in how you solve the more complex problems of the system that is being built. I used a tool to do this for my developers and they loved it. It saved a lot time plus it provided a nice consistent framework for the procedures with all basic error trapping and comment blocks pre-built already. They could use it or modify it as needed.
I agree with this. We shouldn't look to artificially do less of a job than we can. No matter how much stuff is auto-built, there will be work to do in customizing or adapting to specific situations.
October 6, 2010 at 7:36 am
Inconsistent development = lack of conceptual integrity.
Conceptual integrity is what most successful software systems have - a consistent set of well thought out and implemented ideas which provide the underlying robustness of the system.
Conceptual integrity tends to break when you have too many developers and/or poor communication and/or 'average-joe' developers who would rather be doing something else - read the Halloween Papers (Microsoft's reference) about the Cathedral and the Bizzar by Eric Raymond - are good (SQL) developers really 100 times better than bad ones?
October 6, 2010 at 7:45 am
This article caught my attention for a number of reasons. First, I'm maintaining a datamart on which I am the "second guy,: the replacement developer on a system that has just grown without much thought to standards and practically no documentation. Second, I am the lead on two interrelated projects: a new SharePoint intranet and a data warehouse that will drive dashboards on the new intranet. One goal of the projects is to ultimately empower end users to develop applications in SharePoint without needing to write code.
Question: Can RAP and the concepts that the series will discuss be used to develop Web Parts and features for SharePoint?
Jay Bienvenu | http://bienv.com | http://twitter.com/jbnv
October 6, 2010 at 7:51 am
In a typical development the schema design is done by a database guy who is obsessed with micro-optimization of individual tables. He fusses over minimizing table size and deciding things like which tables should get synthetic keys or status fields. The result is a hodgepodge of table designs, all within the same app.
To be blunt, that is just plain wrong.
In a typical development the schema design is done by incompetent developers who have no idea how to model the business entities into a usable database schema. Everything that follows is a gigantic hack in which the same incompetent developers attempt to work around all the problems caused by their terrible databases design.
October 6, 2010 at 7:58 am
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
October 6, 2010 at 8:04 am
I'm kind of lost on the author's perspective though. I don't know of any shop that doesn't work to or towards standards and I certainly don't know of any where the apps and db folks work in vacuums and do not collaborate with each other.
Yes, this is where I landed. Putting the whole lot of us mostly in a pool of those who don't communicate and don't try to create a cohesive system from front to back with others was IMO a bit over the top a way to start the article. It really put me off. I have worked really hard at standards and communication throughout my career, as have the majority of those I have worked with.
I think it's ok to say you have a great idea without dissing those who you are proposing it to...
Maybe the writer has always worked with people who didn't care - that's difficult.
October 6, 2010 at 8:07 am
Where ever you have a top down or bottom up approach, you have compromise where the 2 meet. It really is 2 different problems and both jobs need to be done. I am not comfortable leaving either end to chance.
I have built several auto code generating tools and never been real happy with the results. While they save time for redundant tasks, the reality is application development is rarely cookie cutter.
I think we have come along way in the industry. Code we once had to write ourselves now is available in code libraries such as the Java SDK, .Net framework, and a multitude of others. Today we have documented design patterns. We have application frameworks that solve the problems of logging, reporting, authentication, messaging for us. We have the JRE and CLR that worry about low level tasks for us. Programming languages have become more featured, saving time. SQL Server has more features too. These resources become tried and true over time, which means fewer bugs.
Personally, I am still looking for a good RAD/RAP tool for demos. User’s have trouble understanding what the want, till they see it. I think this is the real value for tools like this.
I hope this tool shortens the search.
October 6, 2010 at 8:28 am
It is true in my experience that procedural developers are completely lost when it comes to effective data modeling and schema design, and that the poor models that result cause continuous and permanent problems forever after with the application.
October 6, 2010 at 8:29 am
Another silver bullet for "what's wrong with software development".
The development of mass production techniques and technology - a difficult, endless evolution - is a far better analogy than mass production itself.
For bespoke software, the analogy isn't a mass produced car - it's a hand built hot rod. That stock Honda will NOT evolve as business conditions change. You can't suddenly add a 6th seat the day the company opens a new office. Often, that's good enough. That's when you don't write bespoke, you buy off the shelf - that is - mass produced!
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.
In this case, it's mass production as initially created by the US War Department, and evolved and improved by many, notably Ford, MOS Technology, and others (including Honda). That's how complex software supporting complex businesses work. Any time someone draws a box around "business rules", you're looking at a massive oversimplification.
We have many benefits from mass production techniques - take .NET for example. It's like the parts bin on the assembly line. RDBMSs are like robots - you don't tell it how to do it, you just tell it what you want done.
There are no silver bullets.
Roger L Reid
Viewing 15 posts - 16 through 30 (of 84 total)
You must be logged in to reply to this topic. Login to reply