Whatever happened to Rapid Application Development?
-
JimmyRopes wrote:
devious
The folks on here who know me well will tell you that this is a perfect summary of me. ;) A basic level of devious is required whenever dealing with clients. Of course, certain other industries require a certain level of deviance.
Deja View - the feeling that you've seen this post before.
-
I'm a developer for a company with a single location, a small transaction volume (30/day), a few vendor and in house apps (.Net/Oracle mostly), and an unlimited IT budget. Our business users are unhappy at how long it takes us to deliver apps, and how often our projects "fail". The reasons seem to be that: a) Our architect won't allow us to develop single layer apps ("what are you, pro-silo?"), instead each must be broken down into a variety of service layers for some future "reusability" that must be distributed across various servers. b) MS is making it harder and harder to code out these layers, by for example replacing .asmx web services with WCF technologies. The problem could also be c) Incompetent developers, but it sure seems like MS' former focus on high level simplicty and business productivity has evaporated. Is RAD even possible anymore? Thanks.
"Architects" X| Web services is a great way of loosely linking systems with minimal dependencies between those systems (and developers). RAD lives and dies by the demo. I like demoing every 2 to 3 weeks, get customers input and make changes to application. I rely a great deal on unit testing to expose breaks in application as application is changed. RAD shows the customer you are making progress. Waterfall puts you in jeopardy because it's more difficult to show progress (requirments matrix, don't even compare to a functional demo).
MrPlankton
(bad guy)"Fear is a hammer, and when the people are beaten finally to the conviction that their existence hangs by a frayed thread, they will be led where they need to go."
(good guy)"Which is where?"
(bad guy)"To a responsible future in a properly managed world."
Dean Koontz, The Good Guy -
gulchgoersf wrote:
each must be broken down into a variety of service layers for some future "reusability" that must be distributed across various servers.
Reusability is the third biggest lie. It is up there with: 1. I love you 2. I ... err, maybe we should skip number two. 3. If we increase the complexibility we will be able to reuse it in all future projects. I am all for reusability and code class libraries for things that will actually be useful in future projects, but to add multiple tiers spread out over a server farm just to produce a report is like putting air conditioning on a bicycle. It is added engineering that will not be useful.
gulchgoersf wrote:
Is RAD even possible anymore?
C# makes development pretty simple. Now if you can convince the Architect that you need a simple span over the brook and not a suspension bridge you can get some pretty rapid results. I always ask the question when people start to over engineer "is this a six month project or a six year project?". That sometimes helps to get them to think within the allocated bugdet, but not always.
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopesJimmyRopes wrote:
putting air conditioning on a bicycle
I'd love to see that and if the price is right... :)
-
I was talking to an architect at a client the other week, and he stated that they were following Agile. I asked him which one and his reply was, "Errm. Just Agile."
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
I was talking to an architect at a client the other week, and he stated that they were following Agile. I asked him which one and his reply was, "Errm. Just Agile."
we claim to be agile, I actually had someone tell me there is only one Agile. I said, no, we are a cross of several. I listed the overlap points, he said he never heard of the others. There was one and only one Agile methodology. I gave up. He's the one who probably wrote it on the toilet that yours read. :)
-
gulchgoersf wrote:
Is RAD even possible anymore?
Oh, definitely. There are three key steps to developing an application rapidly:
- Know what needs to be done. This should be obvious, and i almost just left it out... but, yeah, if you don't know what you'll need to end up with before you begin, then you can't expect to finish quickly. Iterative development isn't a bad thing, and RAD may form the first, prototyping stage of it... but if you just need a tool cobbled together by this evening, waiting on other people to test and evaluate ain't gonna cut it.
- Know how to write software. The first key to RAD is knowing that you can re-invent the wheel if pre-packaged wheels will take too much time for delivery. It gives you leverage, especially combined with
- Don't chase every ball MS throws. You're a developer, not a dog - if you can get the job done faster using ASMX, or ASHX, or a custom HTTP server, or carrier pigeons... then do it. I have it on a reliable source that WCF rocks... but until you have had the time to learn it well enough to be fast using it (i haven't) then write what you need using what you already know.
That's it. Know what you need, know how to get it, don't get distracted.
----
You're right. These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets.
Shog9 wrote:
I have it on a reliable source that WCF rocks
I just got back from a class at DevelopMentor a month ago. We spent a day on WCF. Our current application uses a home-grown TCP/IP sockets-based messaging protocol. While it is robust, there's a lot of "copy/paste" coding that goes on when you add a new message or event. My boss about blew a gasket when I told him we ought to chuck the whole thing in place of WCF, because WCF is freakin' cool. It's what DCOM should have been and was too gut-wrenchingly difficult to learn to get working. DCOM also had severe defects in that you couldn't control error handling and link timeouts.
Software Zen:
delete this;
Fold With Us![^] -
Urgh! A non-software company with an IT department developing internal "enterprise" software, and an "architect". I hope I'll never have to work in such environment.
Nemanja Trifunovic wrote:
Urgh! A non-software company with an IT department developing internal "enterprise" software, and an "architect".
What would you have them do? Buy SAP or Oracle? How do you think people used to get computers to do things before the 1980s?
-
Nemanja Trifunovic wrote:
Urgh! A non-software company with an IT department developing internal "enterprise" software, and an "architect".
What would you have them do? Buy SAP or Oracle? How do you think people used to get computers to do things before the 1980s?
Exactly, like thousands of other companies we have unique systems we have to develop in house.
-
JimmyRopes wrote:
devious
The folks on here who know me well will tell you that this is a perfect summary of me. ;) A basic level of devious is required whenever dealing with clients. Of course, certain other industries require a certain level of deviance.
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
Of course, certain other industries require a certain level of deviance.
Personally, I think the software industry as a whole has earned it's reputation for budget/timeline blowouts from the ingenuousness of the stereotypical programmer types who pioneered the field (who would actually state how long they initially think a project is going to take - must admit, I still do this too often :-O ). 'Bout time we learned to be as underhanded as every other profession :-D .
T-Mac-Oz "When I'm ruler of the universe ... I'm working on it, I'm working on it. I'm just as frustrated as you are. It turns out to be a non-trivial problem." - Linus Torvalds
-
Pete O'Hanlon wrote:
I was talking to an architect at a client the other week, and he stated that they were following Agile. I asked him which one and his reply was, "Errm. Just Agile."
we claim to be agile, I actually had someone tell me there is only one Agile. I said, no, we are a cross of several. I listed the overlap points, he said he never heard of the others. There was one and only one Agile methodology. I gave up. He's the one who probably wrote it on the toilet that yours read. :)
El Corazon wrote:
I actually had someone tell me there is only one Agile. I said, no, we are a cross of several.
Um, isn't Agile just a collection of techniques/strategies/processes that you pick & choose from as appropriate for any given project? So there's no one Agile, or even several Agiles but rather, Agile encompasses a vast multitude of possible project development methodologies? So in a sense, there is only one Agile ('coz Agile covers so many things). Or am I missing something?
T-Mac-Oz "When I'm ruler of the universe ... I'm working on it, I'm working on it. I'm just as frustrated as you are. It turns out to be a non-trivial problem." - Linus Torvalds
-
gulchgoersf wrote:
each must be broken down into a variety of service layers for some future "reusability" that must be distributed across various servers.
Reusability is the third biggest lie. It is up there with: 1. I love you 2. I ... err, maybe we should skip number two. 3. If we increase the complexibility we will be able to reuse it in all future projects. I am all for reusability and code class libraries for things that will actually be useful in future projects, but to add multiple tiers spread out over a server farm just to produce a report is like putting air conditioning on a bicycle. It is added engineering that will not be useful.
gulchgoersf wrote:
Is RAD even possible anymore?
C# makes development pretty simple. Now if you can convince the Architect that you need a simple span over the brook and not a suspension bridge you can get some pretty rapid results. I always ask the question when people start to over engineer "is this a six month project or a six year project?". That sometimes helps to get them to think within the allocated bugdet, but not always.
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopesJimmyRopes wrote:
Reusability is the third biggest lie. It is up there with: 1. I love you 2. I ... err, maybe we should skip number two.
2. I'll call you Or are you thinking of something not-kid-sister-safe? :-D
T-Mac-Oz "When I'm ruler of the universe ... I'm working on it, I'm working on it. I'm just as frustrated as you are. It turns out to be a non-trivial problem." - Linus Torvalds
-
I'm a developer for a company with a single location, a small transaction volume (30/day), a few vendor and in house apps (.Net/Oracle mostly), and an unlimited IT budget. Our business users are unhappy at how long it takes us to deliver apps, and how often our projects "fail". The reasons seem to be that: a) Our architect won't allow us to develop single layer apps ("what are you, pro-silo?"), instead each must be broken down into a variety of service layers for some future "reusability" that must be distributed across various servers. b) MS is making it harder and harder to code out these layers, by for example replacing .asmx web services with WCF technologies. The problem could also be c) Incompetent developers, but it sure seems like MS' former focus on high level simplicty and business productivity has evaporated. Is RAD even possible anymore? Thanks.
gulchgoersf wrote:
Is RAD even possible anymore?
No, it always takes me several days to think of a name for my project and it's artefacts, where I could actually code it in a day. ;P
-
I'm a developer for a company with a single location, a small transaction volume (30/day), a few vendor and in house apps (.Net/Oracle mostly), and an unlimited IT budget. Our business users are unhappy at how long it takes us to deliver apps, and how often our projects "fail". The reasons seem to be that: a) Our architect won't allow us to develop single layer apps ("what are you, pro-silo?"), instead each must be broken down into a variety of service layers for some future "reusability" that must be distributed across various servers. b) MS is making it harder and harder to code out these layers, by for example replacing .asmx web services with WCF technologies. The problem could also be c) Incompetent developers, but it sure seems like MS' former focus on high level simplicty and business productivity has evaporated. Is RAD even possible anymore? Thanks.
The company I work for was bought by another company a few years ago. Their product (to which we have to interface) has layer upon layers of stuff. There are config files everywhere, the whole thing is very opaque. What I'm getting at is that you should KISS. You don't need data acquisitions layer if you only going to read one or two files. That takes care of the late projects. The failed project tell me that either someone did not understand the requirments or the programmers are not as good as they should be. There is something else. Programmers tend to solve problems by coding, even if the problem does not require an application. You get conditioned to approach problems a certain way. If the business people approach you with a problem, look at it carefully and see what makes sense. If you have 2 reports for example and you need a third report, you could either create a whole third report or have a secretary pull the numbers from the reports and add them up (or whatever needs to be done).
-
Shog9 wrote:
I have it on a reliable source that WCF rocks
I just got back from a class at DevelopMentor a month ago. We spent a day on WCF. Our current application uses a home-grown TCP/IP sockets-based messaging protocol. While it is robust, there's a lot of "copy/paste" coding that goes on when you add a new message or event. My boss about blew a gasket when I told him we ought to chuck the whole thing in place of WCF, because WCF is freakin' cool. It's what DCOM should have been and was too gut-wrenchingly difficult to learn to get working. DCOM also had severe defects in that you couldn't control error handling and link timeouts.
Software Zen:
delete this;
Fold With Us![^]Good to see Don Box and DevelopMentor sold you the coolness..industry keeps crushing the dollars. You can control both the 'error handling' and 'link time-out', you just need to dig in deeper. As for WCF, it sings on very similar and sad lines.. and my word is it a pain. Not only is it bloated on start-up and first communication hits which can feel slower than CP when its busy. Duplex channels are crap at performance, config is as verbose as XAML, and whenever you need something extended (like wsdl generation, like dig yourself out of a complex object graph mess, like custom hosting) you better be prepared to do DCOM all over again, but in CLR and XML land. It is easier and appears more easy, but it is a typical bloat of over-engineering. Objects which is your CLR idea and distributed programming do not mix well in any, absolutely any app that requires decent perfromance, ask Google and compare Hotmail vs GMail as an example (no need to go further).. And imagine how slow it would be if they didn't have the native transports backing all over the place (like http.sys, like msmq etc help). Worse than J2-e-messaging-to-phone.. and then people wonder why MS can't catch up.
-
gulchgoersf wrote:
a) Our architect won't allow us to develop single layer apps ("what are you, pro-silo?"), instead each must be broken down into a variety of service layers for some future "reusability" that must be distributed across various servers.
Hmmm. Sounds like your architect doesn't understand why you'd want to layer software - I'm guessing that he has been overpromoted and is well out of his depth. RAD isn't a magic bullet - it doesn't replace solid locked down requirements, and a clear understanding of what the system will do on BOTH sides. RAD only works when you have a partnership between the users and the development team. If you can get the users to actually help in a development, then they have much more of an incentive to help you get it right. Now for the most powerful RAD secret: When your users are with you to see the screens, have something that is obviously and glaringly wrong. When they point it out, and you guide them to the thing you want, they feel that they have contributed. Next time, show them the interface with "their" suggestion incorporated. You can't buy the good will this generates from your users.
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
When your users are with you to see the screens, have something that is obviously and glaringly wrong. When they point it out, and you guide them to the thing you want, they feel that they have contributed. Next time, show them the interface with "their" suggestion incorporated. You can't buy the good will this generates from your users.
That's exactly what we do. If a client suggests adding another column to a grid, changing the text on a button, we usually try it out whilst they're sitting next to us. It's always surprising how impressed they are seeing the 'magic' (as one client calls it) happen right in front of them. It's also a good way of rapidly knocking bad ideas on the head. Oh yes, the architect is over-engineering. I used to work with a chap that did this. He made vast swathes of code incredibly generic and reusable and wrote loads of useful APIs; a laudable effort. Unfortunately he didn't take into account the fact that most of the team weren't the brightest sparks (passing CStrings by value to functions, copy and pasting code rather than factoring it out, that kind of thing) and just weren't likely to need to reuse 90% of the reusable widgets.
-
El Corazon wrote:
I actually had someone tell me there is only one Agile. I said, no, we are a cross of several.
Um, isn't Agile just a collection of techniques/strategies/processes that you pick & choose from as appropriate for any given project? So there's no one Agile, or even several Agiles but rather, Agile encompasses a vast multitude of possible project development methodologies? So in a sense, there is only one Agile ('coz Agile covers so many things). Or am I missing something?
T-Mac-Oz "When I'm ruler of the universe ... I'm working on it, I'm working on it. I'm just as frustrated as you are. It turns out to be a non-trivial problem." - Linus Torvalds
Agile is a collection of methodologies which share certain common characteristics. There is no "just agile", because this shows the person has missed the point. You need to know which bits you are mixing and matching, and that requires you to have knowledge about the strengths and weaknesses of the different methodologies.
Deja View - the feeling that you've seen this post before.
-
Pete O'Hanlon wrote:
Of course, certain other industries require a certain level of deviance.
Personally, I think the software industry as a whole has earned it's reputation for budget/timeline blowouts from the ingenuousness of the stereotypical programmer types who pioneered the field (who would actually state how long they initially think a project is going to take - must admit, I still do this too often :-O ). 'Bout time we learned to be as underhanded as every other profession :-D .
T-Mac-Oz "When I'm ruler of the universe ... I'm working on it, I'm working on it. I'm just as frustrated as you are. It turns out to be a non-trivial problem." - Linus Torvalds
As an old-time developer, we were often (like always) faced with hardware down for days, one test shot per week, working on many different projects at the same time and a dozen other MIS-management problems. One project incurred 2/3rds of its development time finding an operating system bug! But the worst problem: When management asked for a "Quick guess" as to how long a propject would take and that number was what we were held to, even though the specs blossomed out of sight. So we became underhanded, devious, sneaky, lieing, cheating BS artists. But then we got the projects done! RAD was when you bought the system operators coffee so that your test would get bumped to the top of the job queue!
-
El Corazon wrote:
I actually had someone tell me there is only one Agile. I said, no, we are a cross of several.
Um, isn't Agile just a collection of techniques/strategies/processes that you pick & choose from as appropriate for any given project? So there's no one Agile, or even several Agiles but rather, Agile encompasses a vast multitude of possible project development methodologies? So in a sense, there is only one Agile ('coz Agile covers so many things). Or am I missing something?
T-Mac-Oz "When I'm ruler of the universe ... I'm working on it, I'm working on it. I'm just as frustrated as you are. It turns out to be a non-trivial problem." - Linus Torvalds
Nonono! This approach completely fails to meet the requirements of consultants.
-
gulchgoersf wrote:
Is RAD even possible anymore?
Oh, definitely. There are three key steps to developing an application rapidly:
- Know what needs to be done. This should be obvious, and i almost just left it out... but, yeah, if you don't know what you'll need to end up with before you begin, then you can't expect to finish quickly. Iterative development isn't a bad thing, and RAD may form the first, prototyping stage of it... but if you just need a tool cobbled together by this evening, waiting on other people to test and evaluate ain't gonna cut it.
- Know how to write software. The first key to RAD is knowing that you can re-invent the wheel if pre-packaged wheels will take too much time for delivery. It gives you leverage, especially combined with
- Don't chase every ball MS throws. You're a developer, not a dog - if you can get the job done faster using ASMX, or ASHX, or a custom HTTP server, or carrier pigeons... then do it. I have it on a reliable source that WCF rocks... but until you have had the time to learn it well enough to be fast using it (i haven't) then write what you need using what you already know.
That's it. Know what you need, know how to get it, don't get distracted.
----
You're right. These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets.
Shog9 wrote:
Don't chase every ball MS throws. You're a developer, not a dog - if you can get the job done faster using ASMX, or ASHX, or a custom HTTP server, or carrier pigeons... then do it. I have it on a reliable source that WCF rocks... but until you have had the time to learn it well enough to be fast using it (i haven't) then write what you need using what you already know.
That's really good advice. I've been trying to tell that to developers for years but everybody is so caught up in using the latest "cool" gadget that they have forgotten how to think on their own. I'm all for progress but I often wonder how we can continue to develop stable applications when the toolset changes like I change shirts! Fortunately - at least a *little* bit of sanity is setting in to our shop. We've standardized on VS2005 for any of our web stuff (we still have a large base of code that's in VB6) and after getting rid of our "architect" we've stopped just upgrading tools just because they are "cool". Don't even talk to me about VS2010. -CB :D
-
Is what you are building more like a treehouse or more like a nuclear power plant? If you are building a tree house go agile/RAD If you are building a nuclear power station go with up front design and proven engineering If it lies somwhere in between so should your solution
'--8<------------------------ Ex Datis: Duncan Jones Merrion Computing Ltd
Duncan Edwards Jones wrote:
If you are building a tree house go agile/RAD
because when your treehouse collapses it'll only maim/kill your kids and a few of their friends instead of your family, your friends families, your neighbors, their families, etc etc etc. :doh:
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
Every interview I did when I used to do interviews ( that is, as a person being interviewed ) I would say in response to 'what is OO for', 'well, in theory you can reuse the code, but no-one ever does, and over-engineering to build reusable code every time is kind of stupid'. I've been offered a job by everyone who has ever interviewed me, I believe. I can say for sure that every time I've said that, it got a good laugh.
Christian Graus Driven to the arms of OSX by Vista. "Iam doing the browsing center project in vb.net using c# coding" - this is why I don't answer questions much anymore. Oh, and Microsoft doesn't want me to.
When you make multiple derived classes, you're reusing the code of the base class. In MFC if you use a CWnd-derived class, you're reusing thousands of lines of code. Many design patterns (such as Visitor) use OO structures to reuse code. In the pre-OO days, this degree of reuse was rare except if you were using a library. OO technology has made reuse so common we sometimes forget we're doing it.