Slashdot Mirror
Too Much Focus on the Beginning of Software Lifecycle?
rfreedman asks: "Most of the buzz on the web about software development tools, languages, and practices seems to concentrate on getting software developed as quickly as possible. Take, for example, the current huge hype about Ruby on Rails, and how it allows the creation of a CRUD web-database application x-times more quickly than every other environment. It seems to me that this concentration on initial construction of software ignores the issue of total cost of ownership. Most people who develop software also have to maintain it, and have to support changes to it over long periods of time. As has been discussed many times over the years, maintenance is the most expensive part of the software development life-cycle. I think that the software development community would be better served by discussions of how to build more robust, flexible, and maintainable software (thereby driving down TCO), than by the endless discussions that we currently see about how to build it quickly. What do you think?"
Now, how to convince the PHB's and the bean counters?
emt 377 emt 4
The emphasis on fast devlopment is justified, at least from a business perspective, because first to market gives a huge advantage in software, not to mention the network effect. Sure the ability to maintain and upgrade software is somewhat important, but it doesn't matter so much if it takes a long time if you are already dominating the market. Similiarily start-ups don't care about these issues since they plan on being bought out before they matter. Yes these attitudes create serious problems and lead to poorly made software, but what can you do about it? (besides using open source)
Philosophy.
It seems to me that this concentration on initial construction of software ignores the issue of total cost of ownership.
Unfortunately that's how a lot of businesses think and they later regret it if they didn't consider the whole picture before settling on a solution. In lot of cases they just want to have something up and running fast, in some cases, the up-front cost doesn't matter.
I think that as long as there is a bigger influence of non-tech executives and marketing departments, this is going to keep on going.
It's very hard to understand the long term benefits if you don't have some technical skill and have made that mistake a few times.
There should be a balance that clearly isn't there most of the time.
The point of rapid development is the proof of concept. Pretty much every rapid development mantra is centered around.
1) Make it work
2) Make it work right
3) Make it fast.
If you want tightly designed and thought out, the extreme programming style might be more your style. (Or the style of a properly run business..)
(And god help me when someone makes a "4) for profit!!!! LOL WTFASLBBQ" joke, go fuck yourself.
I'm pretty sure a big part of why these frameworks are popular come from the fact that they allow for smarter, fewer lines of code, ultimately making maintenance easier. Much of the lower level problems like database connectivity, optimization, resource management, etc. are handled by these frameworks and other higher level languages which in turn allow the developers to focus on the business logic, rather than debugging their latest build of the database.
At least that's why I assumed rapid developement frameworks caught on.
Well, considering that "product lifetime" discussions are more about process than tools, you're probably not going to see any development tool talk about how it makes maintenance easier. That being said, I've found lots of very good tools related to project maintenance. Continuous integration systems like CruiseControl are fantastic for helping build a very solid, maintanable project.
But for products, you need to have the entire company be on the same page. The company needs to measure and keep everyone on the same page. The only kind of metrics I've ever seen for "product success" are sales figures, which is pretty lame and can be misleading. That aligns your definition of "success" with just making an initial sale; not necessarily making it easy to upgrade, ergo, all the company is concerned with is making more sales; everything else is a cost.
"Most of the buzz on the web about software development tools, languages, and practices seems to concentrate on getting software developed as quickly as possible."
Start your own business and you can develop software as slow as you want. Anyway a lot of the items listed are to handle the increasing complexity of what we're asking computers to do.
that the two concepts must be mutually exclusive. Software can be constructed quickly, and still be "robust" and "maintainable". I will not get into specific development "paradigms" here, but I think that there are options that give us both in varying degrees, on a problem-by-problem basis. Market forces demand flexibility, and those that are, make it.
Managerial Buzzword Count: 3
You have large maintnence costs because no one properly plans up front for the long term. People want to see something and they want to see something fast. No one sits down to write the proper documents, no one sits down to plan ahead, they think for the short term only. Which leads to long term problems down the road. At least, that is what I see as major issues on things i have worked on.
people don't want to make the initial investment to plan ahead, so they end up spending much more in development costs because no one decided where the product should go.
Maintenance? If you can lower the cost of creation enough, it's cheaper to just start from scratch every couple of years. It's the same phenomenon seen in blenders and automobiles. Send it to the landfill and get a new one made.
This phenomenon is only bound to accelerate as software labor costs go through the floor due to offshoring.
STOP . AMERICA . NOW
If Cruise Control (and continuous integration) drives down development and maintenance time, do it!
If it you've got some tool or process laying around to help drive ~any~ part of the software product lifecycle, it will be adopted and used, just like Ruby on Rails has.
Agile Artisans
Software frameworks are not a replacement for software management and development methods. Do you blame the C# libraries for poor software written in it? Do you blame the STL for un-maintanable code? Tools are tools, they should work as efficiently as possible. The person using the tools is responsible for what they do with them.
Slashdot needs a "-1, Wrong" moderation option.
The Urban Hippie
The movement to develop "quick software" is not for the sake of developing something fast at the expense of other concerns. It is meant to address requirements problems, which are the life or death of an applciation.
It's rare for a customer to know what they want. Even worse, alot of development happens without customer involvement. For example, there is usually a huge early requirements meetings, then developers walk away and write code for 6 months. Sure there are demos in between, but they are usually heavily scripted to give the illusion of progress. At the end the developer shows up with a system and the customer wants to change about a bazillion changes.
So...the recent movements in agile or rapid or whatever you call it grew to address these issues. By getting up a functional prototype quickly, you get the customer usuefully involved early in the process. They can use the system and begin to get an idea of what they really want. If you chunk into 4 or 6 week cycles you can have continuous deliverables. And if you focus on everything such as testing, documentation, and deployment from the get go, you can have complete systems for each cycle so you always have demo ready versions. With frequent, complete releases the customers (and management) are much less worried about progress, which means less stress for the developers.
Somewhat idealistic, I know, but it works pretty well.
Help me take back Slashdot. When did 'News for Nerds' become 'FUD and Conspiracy Theories for Extremist Nutjobs'?
"Similiarily start-ups don't care about these issues since they plan on being bought out before they matter. "
Gee, speak it like it's gospel or something. I better not start a company, or some uninvolved slashdotter may suspect my motives.
There's too much focus on the price and features of new razors, and not enough attention paid to the cost of razor blades.
Welcome to life, people. We humans like instant gratification, and if something is easy now, we don't pay a whole lot of attention to what the long term implications are. Same goes for companies.
I'm not belittling the original OP; I think it's a valid point and one that should be paid attention to. I'm just trying to explain why it is not a surprising state of affairs at all.
-b
If I wanted a sig I would have filled in that stupid box.
For years I've been working with pure, vanilla PHP outside of any sort of buzzword framework. That's not to say that my code was unorganized (quite the opposite, I'm pretty anal when it comes to code clarity), just that I believed as the original poster did that MVC frameworks and the like weren't worth the time.
I've recently started experimenting with CakePHP, and it has somewhat changed my thinking on the matter.
A lot of things we tend to do, especially in web development, get repeated over and over. Data validation, SELECT statements and their JOINs, administration backends, login systems... I could go on. In my experience, it's been when I've been bored to death of doing something repetitively that errors would start to creep into my code. It's pure probability: the more you do something, the better chance you have of one of those things having something wrong with it.
RAD solutions posit a solution to this, centralizing all those repetitive things so you avoid having to type the same thing over and over, and thereby reducing the chance that there is an error in any one of those repeated things. If there's an error in the actual framework, one can fix it, ideally, in one location rather than throughout a script (though the frameworks themselves tend to be closely scrutinized to avoid any obvious issues).
I guess what I'm trying to say is that coding less can mean coding better, as long as you understand why you're coding less, and not doing it simply because you can.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
but never time to do it right. How to spot the expert. He/she is the one that says that at a minimum it will cost twice as much and take at twice as long. If it can be done at all.
Undetectable Steganography? Yep, there's an app fo
> What do you think?
:)
Spot on. It's funny to watch people do demonstrations of how quickly Ruby on Rails can be used to build something because it's exactly the same sort of thing that was used to promote WebObjects ten years ago and I know from experience what rubbish it is. For all but the most simplistic applications you have to abandon the mapping of form elements to the database because you need to do validation. If you start off with a RAD approach to problems to these pages and add validation as an afterthought they quickly degenerate into a horrible mess. There will be less of a problem in this respect with ruby on rails because the data layer is so primitive so there are some knots you can't even contemplate being tied into, but - um - what was the point of Ruby on Rails again?
I imagine that doing major schema refactors on Ruby on Rails apps would be a nightmare because there's no easy way to check that you've fixed all the breakages. Whereas if you use EOF or Cayenne and get a culture in your software where developers avoid using key-paths except in agreed spots it's quite easy - you make the change, fix the areas where you find compile problems and then its done.
Something I would be interested to see would be some sort of business logic layer that could emulate a JDBC adaptor. Then you could write your application against that and bind to it as though it were a schema, but in the background it would in fact have business logic behind it. This would allow a separation between business logic and presentation but still allow you to quickly bind applications up as you do in the RAD webapp tools.
Believe with me, my saplings.
I think developing a new project is the fun part. So people focus on how to maximize the enjoyment of doing the activity they like, rather than minimizing the drudgery of the activity they don't. We'd all be better off if more maintenance lessons learned made their way into the software design phase. But people are creatures of habit. They figure if they just push their pet method harder on the next project, it won't be a disaster like it was on the last project. Learning from reality never enters into it.
Behold, this dreamer cometh. Come now, and let us slay him... and we shall see what will become of his dreams.
Quality Assurance is simply the missing ingredients in most projects.
discuss...
One reason these tools get a lot of attention is that using them produces a measurable effect. It's the "bookkeeping fallacy": things that are easy to measure must be more important than things that are hard or impossible to measure.
I do think these rapid development tools can add a lot if they are used intelligently, which I think means using them to present concrete ideas and prototypes quickly, in order to gain understanding of the problem domain and to get user feedback. But I still think Fred Brooks's advice in The Mythical Man-Month is correct: plan to build the first version to throw away. You will in any case, and it's better not to deliver the rubbish to the customer.
The curse of IT has always been, "There's never time to do it right, but there's always time to do it over."
Of course it's stupid and short-sighted. We sacked all of the people who wasted time on anything but the immediate requirements.
Lacking <sarcasm> tags,
There are a huge range of software products out there, one paradigm can't cover all needs. Of course, the biggest mistakes come from applying the wrong process to the wrong market need.
Anything that is intended to last more than 2 years will have substantial maintenance costs, but most managers move on after 2 years or less. No incentive to build it right, ever.
Most developers want to work on something new, leading edge, and they move on as soon as things go into maintenance mode.
It is far easier to react to customer complaints than to plan anything. The excuse is always that we have to keep the customer happy.
A sad lifecycle.
If this was about an application that was going to stick around for quite some time or will be used by millions, then it makes sense to take time and get it done right (witness vista and current office; possibly the first time in MS history where it MIGHT get it right). But in a small company, or a small product, it makes sense to go with Ruby, PHP, perl , etc. Roughly anything that will allow for a fast development, secure, and ok to decent run time. After all, the vast majority of start-ups/ products fail.
I prefer the "u" in honour as it seems to be missing these days.
Most people who develop software also have to maintain it, ...
What???? This may be true with open-source software, but I've yet to see a company that did things this way. The norm is that developers, testers, maintainers and users are four separate groups that are kept as far apart as management can manage.
This does go a long way toward explaining why there's so much crappy software Out There.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Everyone seems to forget that given enough time and resources, *anything is possible in software. Eveyone forgets how _PATHETICLY RETARDED_ business decisions get made (apologies to the mentally challenged who do manage to tie thier shoes). Snide remarks aside, I'm dead serous here. It takes just as much resources, time, and effort to execut a good business idea as it does to do something so fucking stupid it's amazing it was considered in the first palce.
/. masses: Microsoft are a buch of stupid dicks. However, they do one thing (perhaps only one thing) right: they get version 1 out infront of people to figure out what they need to do. Where they go wrong is assuming that 1.2 can be built off the 0.9 beta code base, but that's marketings fault. Given a company with a strong enough technical staff, these things can be corrected. If no strong technical staff exists, then they are doomed anyways and don't know it yet...
Bitch all you want about rapid paths like Ruby On Rails not addressing the long term method, but don't forget the ADD nature of the 6 figure mouth-breathers in the board room. By the time it get's done in a 1/2 assed fashion, you can confirm or deny weather it was worth doing in the first place. Worst case scenario, you have something making money that is hard to deal with. In that case _THROW IT OUT!!!!_ and take into account what you now know for sure about the market/customers/some-sucker-who-will-pay and build the _NEW_ thing that will best make money from them. Too hard you say? Won't work you say? Get some test coverage and push ahead. If you don't, just go home now, because your competition will. Adapt or die. In a global market place, you can't affort to buy "what if" engineering dollars.
Arguments like "We need something that will respond to something we don't know yet" is a variation on big design up front and other various sorts of "slow" waterfall mentality to building software. Yes, I'll admit to being one of those annoying agile assholes, but for 80% of the "business decisions" that get made in the corporate IT (and even startup) world, it holds true: the guys in suits don't know what they are doing. There are numerous reasons why Fredrick P. Brooks said in The Mythical Man Month (now over a quarter century old!) "build one to throw away. You will anyways" was because the nature of business hasn't changed. Anyone selling you some path to something you don't need today needs to be avoided like the plague.
I'll agreee with the
To summarize: this argumet is a load of crap presented by people who want to cling to "proven-to-fail" approaches to building sofware. It's not a bridge, it's not a car, it's ones and zeroes that may or may not see the light of day. The same optimization axion aobut "never prematurely optimize" applies even better to "never assume you have it right". As soon as people drop they fronts of how much they think they know about building products, the better off we all will be. Try, learn, and adapt. Again, if you don't your competition will...
Footnote: * within reason. You're not going to create a miracle, but you know what I mean here...
*** Sigs are a stupid waste of bandwidth.
Too often, software is released and it's shitty. We need more of a focus on quality assurance.
Test Cases, TPS Reports
Test Programs, Test Harnesses
Automated Testing in General
Release Cycles and Branches
Bug Databases and Bug Tracking
We need to take the defects per line from 1 in a hundred to 1 in a hundred thousand.
I work in support for a tech company that sells large software packages to Fortune 500 companies. The director of Support made a presentation on software maintainability to the Engineering department in which he displayed a spreadsheet showing that the fact that our binaries can't report their hotfix level (our customers always end up running hotfixed binaries) adds an average of 5 minutes to every support case while we determine the hotfix level, with a cost to end users at around $100,000 a year in lost productivity for production down issues. That was one of several areas he identified where the lack of engineering the software for the purpose of supportability had a calculable cost to customers.
Beyond code maintainability for future engineers, think about the job of the support engineer who's the human face on your software over the years. Think about how the company and the software looks while the support engineer asks for things like the binary size to determine the hotfix level, or says "if we logged that, we would know; let me send you an instrumented build." Especially for software maintained by IT departments, the longer impression of your software is determined by how effective your support engineers are, and how effective they appear to be to the customer.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
So - agile sw happens because smart programmers know that management has no clue about requirements, so why waste time on requirements, just write some code?
STOP . AMERICA . NOW
Just out of curiousity, what are we supposed to stop America from doing? Freeing Iraq? Should we force America to give Iraq back to Saddam Hussein?
But then, I'm one of those weird Europeans who thinks that it's actually good that we might get a free democracy in the middle east. I seem to be in the minority, which is rather bizarre, I must say. Sometimes I think my countrymen are too busy feeling powerless in the world to notice that some good things are happening.
"I think Microsoft would be the ideal company to write this book. I hear they've found a way to reduce their 6-year development cycle after the release of Vista!!"
or
"You want us to maintain your outsourced code too??? Oh, that's going to cost you a lot more. Of course you can always do it yourself but we didn't write any of the comments in English."
It's not the language or the tools that lead to maintainable code. It is entirely the quality of the people who architect and implement it in the first place. An experienced, well educated developer will always write with the future in mind, with commenting and clear abstractions. In converse, no language can prevent sloppy coding - and sloppy coding is the only cause of unmaintainable applications. Full stop.
What language and toolset benchmarks do is show how easy it is to express ideas, which is a pretty useful benchmark (as in approximation) for how well a good developer can use that language.
Looking for a Rails developer in Chapel Hill?
Considering I have fewer lines of code than I had configuration files, I'd say this is way more maintainable. And fewer LOC's usually means fewer bugs, therefore less maintenance.
Oh, and Rails is about much more than rapid CRUD. Although scaffolding (the automatic generation of CRUD pages for a table) is damned handy in some cases, it's expected you'll replace most of it for any non-trivial application.
But as for TCO, and startup costs. If you're starting a company based on software, would you rather
A: Spend 1-200 hours building something to see if there's a market knowing you'll have to rewrite the whole thing
B: Spend 500 hours doing it "right" and then realizing you either have no demand, or people didn't want the features you put in
Ok, that's not much of a choice is it? All that pre-planning stuff is premature optimization. If you can build it fast AND CLEAN, you'll be able to fix it. Most importantly, you'll still be in the game.
Information: "I want to be anthropomorphized"
practices seems to concentrate on getting software developed as quickly as possible
That's because the time it takes to get your software to the market is often just as important as the TCO.
We already have a free democracy in the middle east. It's called "Israel". Or do you think that it doesn't count because it's run by Jews? Take your anti-semitism elsewhere, please.
I'm something of an old-school Lisp hacker.. these days I use languages like Ruby and Perl. This "agile" stuff warms the cockles of my paren-matching heart.
What Ruby on Rails does for you is create a domain-specific language. It takes all that stuff that you repeat over and over and factors it out. Which means less code, clearer code, and so forth. Yes, this makes it easy to throw apps together, but it also makes it easier to maintain them, test them, change them, and improve them!
All the well-written programs I've seen have this quality.. they look like pseudocode taken from the problem domain, so it's easy to rearrange the code and add new functionality. This makes it really easy to maintain. All the nouns and verbs are laid out, all the important degrees of freedom are there.
So, if you want to focus on rapid development, go ahead.. but keep in mind that the exact same qualities that make it easy to got from 0-60 also make it easy to go from 60-100, 100-200, etc.
You may be right about the TOC and maintenance. RoR really does make creation of CRUD apps simple and fast. However, it's hard to tell what the TOC and maintenance of RoR is like yet, as RoR only recently started getting heavy use outside the country of its origin, Japan. It's too early, I think. In other words, we have to wait for a few years to pass, let some people build non-toy RoR apps, and then look back and try to judge what maintenance was like. :)
A pile of new Web 2.0 companies are using RoR to get their products out quickly. We'll see how many of them survive long enough to tell a maintenance and TOC story.
Simpy
I think the problem isn't that there is too MUCH focus on the beginning of the software lifecycle. The problem is that there is too LITTLE focus on the beginning of the software lifecycle.
The beginning of the software lifecycle is supposed to consist of analysis and design - both of which can lead to the construction of a superior product if done right. The issue is that many of these "quick start" languages and frameworks make is easy for a programmer to dive right into the coding phase without considering the overall design of the system. Thus, they skip the beginning steps in the software lifecycle.
------
www.moneybythenumbers.com
here is your potato salad.
now go to hell
I clicked on one of your articles
and got a 4o4
lame ass editor
for you, nothing more
except to tell yea
to go fuck yerself up the arse
max von sydow
represents the Beat culture
and you represent
the beat culture
beat with a pole of carbon fiber
find a new job, hack!
Where I work we have "Quality Assurance". They are great at making sure the copyright is correct on a document and they know how to use spellcheck.
I love when "Quality Assurance" shows up at a code review. Yep the header has the copyright statement. My job is done.
This isn't a knock at the idea of Quality Assurance, the idea is great, but I have yet to see it implemented in any way that is useful.
Seriously, a good portion of the religious wars floating around (slashdot) are from people who slam out one-offs and the likes. Long term software development breaks down very quickly in many of the oft-touted IDEs.
A great development environment must have:
- first and foremost, a fantastic text editor
- tight integration with version control
- good refactoring
Tools which focus on "code by click" simply fail because they only solve 80% of the initial release and much less of future releases.It's a simple matter of complex programming.
My experience is that I get huge long-term benefits, not just the faster up-front development. The main reason I develop in rails is that I have much easier long-term maintenance, and making changes to applications has been easy. Way easier than the php code that I have out there.
Put another way, I think your rails slam is unjustified.
Do you have ESP?
I am a software developer. I get paid to develop software. Business people do not give annual raises to software developers in line with the rising cost of living. They feel that they pay too much and they exploit inflation to drive the price down.
To maintain my income I must change jobs regularly. To demand a premium and obtain my increase in pay at the change of jobs I must keep up with evolving tech trends and remain buzzword compliant.
Maintenance roles will prevent me from doing this. I've made this mistake and I'm not making it again. For economic reasons I will not accept a maintenance role. It's as boring as it is dangerous to my career.
Yes, I'm stealing the title of Alan Cooper's book
You have to basically be two-faced about any development. Be gung-ho to management types, show them what they want to see, but once they are gone, do the development right. It can seem like a pirate-type undertaking sometimes. You have to sneak out and interview users while they are on break. Take up smoking. You'll gather the best information that way. Gather real usage details. People like to talk about their work, so this isn't really all that hard, but it seems non-productive to management types.
Okay, being a bit more serious, it's up to you as a programmer to decide how you want to approach any project. Never mind the micro-managing boss. He probably doesn't know what he's doing, either. Decide for yourself what effort needs to be done and if it makes you feel better laying down a decent foundation from the start, do it. If you've got crap to work with, refactor and repurpose.
Toolsets, in and of themselves, don't solve problems. The fundamentals of designing, and more importantly, not over-designing, your project does. Read Cooper's book. Seek out books by Raskin, Thomas, and Hunt. They all say the same thing, if in different ways. Doing the work right the first time will make you money in the long run. Actively fight back against management that keeps wanting to change the requirements and doesn't know what they are doing. Be passionate about what you do. And if you get fired, it will be for a damn good reason. Don't play their game, play yours. Most importantly, enjoy what you do. If you don't like it, go do something else.
So you take 2 years writing specs, another two years developing and guess what, when the project is out it is based on obsolete technology and business rules.
The biggest mistake management make is to use the building-a-bridge analogy to software project management, that is what they have been trying (and failing) to do in the last 30 years. It is proven to be a bad way to develop software. Agile Development was born from fustrated Project Managers looking for a better way to do this. Agile Processes have more than 10 years delivering better quality much faster.
HTML is obsolete. It's time for a new, simpler and richer markup language.
All the more reason to get to a "dog food" release as soon as possible, so users can actually start using the application instead of just playing with it. Of course, it's hard to convince people to switch until the new system is better than the old one, but that's the point at which truly valuable feedback is inevitable. Until it's being used for real, you're likely to get only cursory feedback from most users.
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
I worked for an outfit on the west coast last year for a few months during a systems transition. One of the principals came to me one day and asked what was taking so long. He was an old school COBOL programmer from nineteen tickity two who didn't really understand oop and the monstrosity his company was building so I tried to walk him through what we were doing, saying in the process that I was working at getting it right the first time. I'm always thinking in terms of maintenance down the road. He flipped out and said, "I don't want it right, I want it now!" I kid you not.
I don't work for them anymore.
I understood his point of view however. He needed to get buttons and clicky things in front of the customers as fast as possible. It seems customers will accept the mediocre over waiting and those folks are running a highly successful business as well a creating a giant mess for themselves in the repository.
In the end it seems that people will accept garbage over nothing. I personally don't subscribe to that philosophy but the reality seems to be that it does make for a pile of money.
This is exactly why I selected Eiffel for a signifiant simulation project that survivied seven years of maintenance. There simply isn't a language that better supports maintenance. It's not just a programming language--it's a lifestyle!
totally agree.
i have not made any software systems which i have not made more money on the maintenance of than the original development.
i wish the same could be said about web development (excluding web APPLICATIONS) where all the focus is on pushing really tedious work out the door then making it all user updatable so once you do your really hard yards, you leave no work for yourself in the longrun.
I think that the software development community would be better served by discussions of how to build more robust, flexible, and maintainable software (thereby driving down TCO), than by the endless discussions that we currently see about how to build it quickly. What do you think?
As someone who started his professional development life maintaining other people's code, I completely agree.
But I must take issue with the title of this thread. The problem isn't too much focus on the beginning of the software lifecycle. Coding is in the middle, not the beginning. A good design comes first, and a good analysis of the problem domain before that. Modern methodologies ignore design, or pretend to do during coding. A quick and dirty hack may come back to bite the heel of a future maintainer, but a hurried design is sure to smother him to death. Way too much emphasis is made on coding, but that's only 10% to 20% of the lifecycle (not counting maintenance).
We're not developing faster, we're just shipping more prototypes.
Don't blame me, I didn't vote for either of them!
It don't matter how much you save. Even if that week shutdown paid itself back in the next week it would still often be considered too expensive. Because one week of non-deliveries, one week of the customer going to the competitor to get what he needs is considered far more costly then day in day out small losses because of ineffeciency.
When it comes to IT this is compounded by the many horror stories of runaway IT projects that just don't finish and always go over budget. Sure sure, they say, an advanced IT tracking system would save us a bundle each and every day but only after we spend 3 years on getting it installed and then it will break down on everyday with a y in it.
For software development itself this means that people have come to accept that software needs costly maintenance. So why prolong the development to save costs you are not going to save anyway?
A F1 engine is going to be stripped down after a race anyway so why bother making it reliable enough to last more then one race?
And don't forget that software deployment is often a race. Software is rarely written in advance. Usually it would preferabbly be ready yesterday. Have you ever had a project were a company said, we predict that we have a need for a new system in 3 years so get to work? No, 99% of the time it is, we needed a new system years ago so can you have it done by yesterday?
Good luck then pointing out that if only you spend a little more time on it you can make it easier to maintain in 3 years time. They want it NOW!
Learning to accept this is the only way of not going insane at work. Offcourse if you have learned to accept this you will also have become part of the problem. One of the suits who can't see reason.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Each approach has a place in the ecosystem. Reiser4 could only have been developed the slow way, but that was because we were going into a mature market with solutions that worked already in place. We needed to architect for maintainability because we knew it was a long hard road ahead, and we weren't going to be quitting soon, so we made a plugin architecture.
The problem we have is when the grasses dis the trees and the trees dis the grasses. The Linux Kernel Community, and the rest of society, have too much of that going on.
Respect those who are nothing like you, and see that they have value to society that you cannot match but might complement.
Some arguments for concentrating on a quick, inexpensive initial implementation:
- the application cannot help the business make and/or save money until it is running; a two month delay in initial implementation may cost a fortune;
- even applications you expect to use for a long time often do not work out that way; further, the longer you take giving the user a solution, the more likely some manager is to "reconsider" the value of the project part way through;
- the time value of money; money spent early in a application life cycle is more "expensive" money than money spent later.
The other side of the coin:- an inflexible application may mean that opportunities are lost later; the ability to react quickly to changing requirements is very important;
- developer morale; if your development team feels they are being forced by PHBs to do shoddy work, the impact on motivation and staff turnover can hurt badly.
The various factors must be weighed carefully on a case-by-case basis. Once the decision on approach is taken (especially if "quality" is being compromised) it is important to transmit to the development team why this is the correct approach, from a business standpoint, on this occasion.Often the best answer is to use different strategies for different parts of the project. Availability of reuseable code from earlier projects is sometimes important to the decision process.
Bottom line: speed and cost of initial deployment is important, but can be overdone.
Yes. We should definitely do that. It would be the best thing for--Oooh! Look! Shiny Things!
By the time your maintanable app is on the market, the Shiny Things have beat you.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Where is it? When I have written software in the past, I've seen rapid development and maintainability go hand in hand.
If you want to finish a software project quickly, your code must be written with a certain level of foresight. You can't just hammer things together, but you must also put in some design effort to make sure that the structure accommodates the functionality you're shooting for. When you do this, your software will be developed faster than any other method because software lends itself to its purpose--your project runs the risk of dying before its finished if you don't. Your software will also have its own intrinsic flexibility toward its application. That means that a clean, solid application will come together more rapidly (and is coincidentally easier to maintain).
Are you familiar with the MVC paradigm at all? Rails uses this, and enables logical separation of the three major components: Model, View, and Controller. I'm going to assume that if you care at all, that you'll do more of your own research; either that or you already know what MVC is but were unaware that rails used it. My point is that most of the code you see in those 15-minute-blog demos are either completly devoid of controller code, or just scraping by with the bare minimum to pass data downstream. The controller's purpose is to validate and format code, and/or carry out other logical adjustments. Just because some crappy demos skip this part doesn't mean that RoR doesn't have this capability. I'm a professional RoR coder myself, and I think I find those demos about as dumb as you do. All it means is that rails is likely to suffer from the same sort of newbie coder problems that many people find with php/mysql. Plopping an inexperienced coder in front of the next greatest thing in software development is going to yield poor code no matter what the platform is. Also, I'm not sure why you consider the data layer primative, but at this point I'm going to assume that it was just ignorance and assumption talking. I don't really mean that as an insult, but rather a suggestion that you should do some research on what you're slamming so hard.
Beware he who would deny you access to information, for in his heart he dreams himself your master. -Anonymous
The first point is probably the most relevant - small companies are going to have louder people on the internet. Small companies are doing cutting edge stuff. People want to hear about cutting edge stuff. Enterprise Cobol developers aren't big on blogging from what I can tell.
i think the premise is false. it sounds like the intro writer believe that ror sacrificed organization in order to imporve speed of development. imho, ror is organized very well and this is the reason why one can develop so fast for relevant application.
yes, you have to learn the ror rails way fo doing things. once you learn the rational and reasonable way that things are organized, it isn't necessarily more difficult to maintain your application. rather, it is often much easier to maintain your app.
this seems like so much hot air to me... but it made front page on slashdot, right?
what do i know?
Good
Fast
Cheap
Pick any two...
We should start referring to processes which run in the background by their correct technical name... paenguins.
RAD is a process ideally suited to customer-oriented development.
Customer-oriented development is where a client comes to you with a rough specification and says, "we need a program that can do this, this, this and this." You sit down with the client and discuss more specific implementation details: individual features, user interface design, workflow. You have a well-defined specification of what your application should do. You give your client a projected timetable of six months to project completion.
Five months into the project, over a period of time in which you've spent countless man-hours refining a framework that reduces TCO, meticulously commenting every class and routine you've written, you show a prototype to your client and the client says, "No, this isn't going to work at all. The entire way that the workflow proceeds is too confusing for the target users of the program. It looked great on paper, but with the database populated with real information it's entirely too much for somebody to take in. "That's what was in the spec," you argue, but the client won't hear it. The six-month project will now take eight and a half months as the entire process is reworked.
What rapid application development allows you to do is to demonstrate a prototype in the least amount of time possible. Instead of the five-month mark, you have a product that can be demonstrated at the one-month mark. Most of the features don't work yet, and the ones that do are slow, unoptimized implementations, but it gives you something to present to the client that allows them to go "can you change this?" before you waste months implementing things that don't work nearly as well in practice as in theory. It gives the project more flexibility than a traditional development methodology by allowing you to change the program specifications before changing the specifications results in breaking the program. The query automatically generated by Rails's ActiveRecord may not be as optimized as the hand-optimized SQL you could have churned out, but you wrote the entire database interaction for a controller in literally four or five minutes. You can show it to the client, get his thumbs-up, and then replace it with the hand-optimized stuff. If the requirements change, you haven't wasted any time writing code that you need to gut out and rewrite anyway.
The goal of Ruby on Rails, Django, and TurboGears isn't to replace the entire J2EE stack for companies like eBay or Citibank; it serves a totally different purpose. The scaffolding in Rails in particular allows you to automatically generate a basic user interface from the database schema without touching a line of code in order to prototype, and then slowly replace the scaffolding in bits and pieces until you have a full working application. It provides you with the agility to catch design issues early in the development lifecycle, rather than at the very end.
TCO is unimportant when you have API and data format inertia to keep fat streams of revenue flowing forever.
We have two major systems at the company I work for. One, that the related staff spent 2 years documenting their business practices and exactly what they wanted the application to do. They took that huge document to a couple of consulting companies and said "we want this." 2 years later the consulting company that won the bid turned over a nearly perfect application.
Wow. Sounds like a ringing endorsement for planning and quality execution.
Unfortunately, though I've tried time and time again, I've never gotten anywhere near the participation required to lay out everything in advance accurately. Worse, the few times I've actually managed to get something together and gotten everybody to sign (in blood) in triplicate, it was rejected on the very first day of rollout because they didn't expect something that was, upon rollout, patently obvious. In my experience, people don't know what they want until they see that you have isn't it. Very few people have the intelligence and foresight to extrapolate what a screenshot will mean to them, in the real world.
So, I've turned my back on the whole idea, and have instead adopted a modified "agile development" approach.
I do just enough specifications to determine how all the pieces are going to fit together, what all the database fields are, and how the constraints, triggers, and foreign keys assure reasonably sound data. I beat the idea in front of a few people and search for objections, until most people approached seem to like the idea, and nobody has any major bones to pick.
Then we code - it goes out the door for public release as soon as it seems stable and workable. I don't bother trying to make it totally bug free, so QA is short and sweet. On rollout, I ask our clients to review it and inform us of any bugs. We never get it right the first time, and we're pretty up front about that. But we fix it quickly, and most importantly, we modify our software towards what the customer actually needs. Stuff that is simply not needed gets dropped pretty fast.
Our software is designed to "fail early" - so that inconsistent or inaccurate data doesn't hurt anything. And so far, we've had only minor issues in over 2 years of heavy, active, exponential growth and development.
Turnaround time for an average modification is less than a week. We issued over 40 releases in the last year alone. Every so often I go over everything in a new perspective, and do a bunch of minor tweaks all at once - that's when UI improvements come down hot and heavy.
The response has been wonderful! A customer who mentions an idea, and sees it implemented a few weeks later is your evangelist for life. You practically become their religeon, and you'll get recommendations and referrals for the rest of your days.
I've heard people talk about it like bargain hunting - they hunt around - just to see what's new!
So far removed from the bleak hopelessness so common here at Slashdot about software projects - it's exciting, intense, fun, and profitable!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
But I still think Fred Brooks's advice in The Mythical Man-Month is correct: plan to build the first version to throw away. You will in any case, and it's better not to deliver the rubbish to the customer.
I'd take it further than that. My experience over the last 10 years of development work has been that for any medium-large project (the smallest I've worked on that this has applied to was an e-commerce system that has about 9,000 lines of code, the largest was a GUI framework that has about 40,000) was that the first version really didn't work well at all and could only be used internally; the second version was adequate for a few years of customer work but starting fraying at the edges after that; it was the third version, another rewrite from scratch, that actually managed to both work and be maintainable.
So for the first version, at least, agile tools and methods are probably appropriate. If you're going to throw it away, you might as well get it done quickly. For larger projects, it might be appropriate to take a similar approach for the second... just document it better, because you will be working with it for a year or two at least.
This quote just happened to appear at the base of this article: "Your reasoning is excellent -- it's only your basic assumptions that are wrong." Let us assume that business concerns dictate software development cycles to some degree. Certainly a developer can sympathize with the pressures of competitive business urgency. However, I think there's a tendency (especially in startups) for the quality of a business concept to be inversely related to the "need" for fast time to market. An extremely poor idea, for instance, might appeal to extremely fast development so that its weak business model doesn't collapse under even basic competition, whereas a unique and fruitful concept may deserve quality software development attention. Organizations that expect "poor" software development can themselves be indicative of a weak business plan. If the business concept foundation isn't solid, there is no reason to expect the business drivers to want anything but fast and cheap software results. The lack of appreciation toward software development is a reflection of a bad business. Bad input, bad output. To argue that rapid and vapid software development is justifiable for business reasons is a logical misstep if we don't also ask what it is that justifies bad business? For businesses that possess a reasonable product concept with quality management that finds itself in need of hazardously rapid software production, this message is not for you. Let's just make sure we don't allow the debate between rapid and pensive software development to be unduly influenced by immature businesses that believe that unsophisticated, bare-knuckled business practices should be reflected in an engineering discipline. There is a reason why software developers are not allowed to fail but salespersons are. There is simply a different scale of rigor, knowledge, and discipline involved. Business principals won't like to hear it, but it's the sad truth, and it's the world we live in. I doubt that any of this will change, as it's really as much about human nature, fallibility, sometimes corruption. But for our own sanity, if we can't change it, at least there is some solace in the knowledge that we can work to find solutions to genuine problems but that we are often doomed by faulty or simply missing business premises.
Sadly, this is the hype about Rails, a feature called "scaffolding" which lets you build a CRUD web-database application by writing a single line of code. This is pretty much the first feature anyone who touches Rails learns about, and sadly, it appears to be the only feature of Rails the author of the question has been exposed to. Scaffolding is, perhaps, the least interesting feature of Rails.
I've been developing a fairly high profile web site in Rails for the past year (ClickCaster.com). In the past I've used a number of different web development languages and frameworks, particularly PHP and JSP. Rails has not only resulted in the fastest development of any framework I've used, but also the tersest code to implement given functionality.
The real advantage of Rails comes from two different aspects: leveraging Agile development techniques, and exposing a highly cohesive, high-level interface for developing database-backed web pages.
The former, particularly the practice of test driven development in which you write tests first and code second ensures you think about what your code is trying to do first and how it should do that second. Pro-actively writing tests ensures that making modifications to your code does not break existing functionality.
The latter, which forces your code into an MVC model where database, mailer, and other underlying components are neatly isolated from the rest of the program logic, and the presentation templates are isolated from code receiving and processing user input, all atop a very high level framework where the majority of development tasks are abstracted ensures you write terse code which is well modularized by function. This has two advantages: it makes code easy to write in the first place, and it makes it easier to maintain. The author of the question seems to imply that Rails satisfies the former condition, but not the latter. This is not the case.
Rails results in less code, and uses test driven development which ensures that your changes do not break existing functionality, and all you need run to ensure this is "rake test". Bottom line: less code is easier to maintain, and tests prevent modifications from breaking existing functionality. Thus any implied criticism against Rails in this article is completely unwarranted and only serves to illustrate the ignorance of the question's author, not any imagined deficiencies in the Rails framework.
Every euro put into developing code results in additional four euros to maintain this code later. Do you really think writing more code faster is solving any business problem?
Constantly rewriting software is out of question. Legacy software was once written, debugged and spent some time in maintenance. Why do you think you can rewrite the same logic and safe money by doing so?
Writing new software creates a growing wave of maintenance cost following the development activity. Once this catches up with you, you spend all your IT budget in maintenance and you will be unable to fullfill new business requirements. The only way to keep operational is to find ways to do more with the same amount of code. Existing code has to be well structured and documented so that the business logic therein can be reused. Dependencies between systems have to be well controlled to keep the code base maintainable. Nobody can afford or risk major changes of the application landscape.
All this is about architecture and design with a long term outlook. It is not about writing code...
There are different styles of business, just as there are different styles of programming. Some feel that business is like a WWF fight, whereas other conduct business calmly and earnestly. The excitable, frenetic form that is indistinguishable from bi-polar syndromes is simply weaker and fundamentally less stable albeit perhaps more likely to win the lottery.
If a kid is on a sugar high and deems it necessary to feed his craving at the local corner store, he is probably not considering the most effective and efficient route to his continued satisfaction but rather the easiest and fastest road to his immediate gratification. This is the same type of behavior we find in drug addicts that will sacrifice everything for instant relief. If a business is to be handled in this fashion, the facilitators will have to accept this lack of vision. I suspect that it's up to us as developers to decide if we need to work for organizations with some self-respect and quality products or if we shall succomb to consorting with mud-wrestlers or drifting with pirates.
We simply cannot equate a business motiviation with the engineering process methodology, especially when a business is not a Business (with a capital B) but just an ordinary, everyday punk opportunity for some two-bit egoist mongrels.
A business might be entitled to make its own decisions, but like anything else, the act of sovereignty does not make a Business, in the same way as late night karaoke stint doesn't make a Hollywood actor. Business people and managers that don't bother to look past their own fake smiles are just the fools we work for. We are the of jesters of kings and pompadours but who is the greater buffoon, the one that struggles to keep a sinking ship afloat or the one that bought a boat with holes?
> Take your anti-semitism elsewhere
Dickhead. Put words in people's mouths and then label it
anti-semtism. Maybe he forgot Israel was in middle east,
last I checked ignorance and anti-semitism were not the
same thing. And there are other reasons for not counting
Israel as a proper democracy [eg that voting rights are partially
based on race].
http://rareformnewmedia.com/
Here's how to convince the beancounters. Show them how,even before the TCO gets so out of control, the product it supports - or even is - ends up being something nobody really wants anyway. Start with the end in mind; both from maintenance & customer demand = revenues & profits! This a SWD co. in NJ that doesn't write a single line of code until the end-user manual is written. There's actually a book out with that title, "So You Built It and They Didn't Come. Now What? on Amazon. Will they never learn?
I think that if you don't get the project out the door ASAP, then there will be no money coming in to pay for all those expensive maintenance programmers. Besides which, unless someone is actually using the project, how are you going to know what to maintain?
Now, there is certainly justification for the maintenance team refusing to accept code until it meets certain criteria, but there is no need for those criteria to get in the way of customer release. They are two seperate issues.
That thought is terribly flawed, at least from a small business' perspective. Rapid software development is key. For one main reason. Before you have a product it makes you $0. After you launch it (assuming you do a good job) it makes revenue and can pay for its maintenance. Its now making you money instead of costing you money. It may not matter to MS, but to small business it means the world.
It's simple logic really, and you'll find it's how most small-medium software companies look at it. We may hear a lot about the big guys (Adobe, MS, Apple, etc.), but there are 1000s more that are small. For them developing a new product can decide whether they sink or swim TODAY.
Let's face it, we would all rather take a slightly less profit and actually have a PROFIT then to wind up never getting anything at all because its development costs were so high.
From the freelancer's perspective, there is nothing I love better than a mess of spaghetti code hacked together by interns on crack and then rushed out the door by a PHB.
Where I might normally charge $250 for a few hours of patching, these desperate fools will happily pay 10x that so long as it "works by Monday morning". Of course, that's pretty easy to deliver, especially considering the PHB will almost always elect to avoid all the *real* problems (read: time-consuming). The result? Repeat business!
I used to feel kinda crooked about this (honest). But, in all fairness, a man can only give the same "TCO is relevant!" power point presentation so many times before he just gives up and takes the money.
barack to the future?
Ruby on Rails is not designed for the software engineer. It's designed for the Glue Master who wants/needs an application developed as quickly as possible with as much power as possible. The applications are "quick and dirty" one-offs that will be "refined" by being rewritten. Perfect for Web-UI's that need to be constantly scrapped and rewritten. Typical programming team consists of a single ADD user (not usually a "learned" programmer).
PHP/Python/VB is not designed for the software engineer. It's designed for the programmer who wants/needs an application that is maintainable and will last longer than a RonR app - but is is not going to last indefinately. The applications will have a history and may be revisited and refined for several years. Perfect for heavily used Web Apps that have a short-multi-year lifespans. Typical programming team consists of 1-4 programmers optionally with some support staff and/or managment.
Java/C/C++ is designed for the software engineer and programmer who wants/needs a robust powerful application that will have 5's and 10's of years lifespan - Perfect for building something like a PHP/Ruby on Rails/Web script engine, Apache Web Server, Linux OS, etc. Typical programming team consists of multiple groups of 6 programmers/engineers and staff (managment, testing units) to support them.
It doesn't make sense to over-engineer applications that process simple web-forms. Nor does it make sense to hack together a web-content-management-system. You use the tools, the effort, and the language that makes sense for the application at hand.
-CF
n/t
I totally agree with this article. The issue is not only that we don't focus enough on the rest of the cycle, but also that we have no understanding of it.
The best work in the field is the so called "FEAST hypothesis" http://www.doc.ic.ac.uk/~mml/feast/. What they say is that systems evolve along an inverse square rule. But there are catches. The big issue in systems is not growing size, but growing complexity. Simple code is easy to maintain, complex code is a nightmare. The biggest catch though is in the data. I have later data for one of the systems studied by the FEAST project. It grew from 3.1 mloc to 3.9 mloc in the projects study period, along an inverse square form. If the system had continued to grow at that trend it would be 4.5 (ish) mloc today.
In fact it's 13mloc and it's become the nexus of an ecosystem of 400 systems connected to it via XML middle ware.
We know squat.
--------------------------------------------- "In the end, we're all just water and old stars."
Service Oriented Architecture
(SOA)
--- -- - -
Give me LIBERTY, or give me a check.
It is apparent you don't know what you are talking about at all. I recommend actually reading up on what you can do. I developed in WO for about two years, and that was absolute crap you are right - but the idea was sound. And Rails is in many ways WO done right.
The reason you want to be able to build a working system quickly is so that you can throw out the first one. You see, there is no substitute for learning how to do something than to actually do it. Trouble is that, if you invest a lot in the first one with an eye to reducing maintenance costs, you won't be willing to throw it out even though the entire structure of the program is fucked. A program is founded on a certain set of assumptions. If your assumptions are wrong, then the foundation of your program is wrong. Your program can never be fixed. It must be thrown out, and a new program with correct assumptions must be written.
The second system will also be fucked, because you are a sophomore. It, too, must be thrown out. Only until you get to version 3.0 will you actually have a working system which should and will last for the lifetime of the product. THEN you worry about maintenance.
Don't piss off The Angry Economist
http://delivery.acm.org/10.1145/810000/803691/p303 -mclean.pdf?key1=803691&key2=8402792511&coll=porta l&dl=ACM&CFID=15151515&CFTOKEN=6184618
Write it right the first time you're in good shape. If you didn't write it right, it's probobly faster to throw it away and start over anyway.
What are you blabbering about? If you are a citizen, then you can vote -- whether you're Jewish, Arab, or from Martian.
You must be thinking about the West Bank, where people there aren't citizens (let's ignore the settlers for a moment), since it was never annexed like the Golan Heights, hence it is not officially part of Israel; this also applies to Gaza.
Which do you really prefer?
If the system is done right, the fact that it's quick to implement initially means that there's not all that much code there (because you wouldn't have time to write it), which means that it's relatively small and therefore there isn't too much to maintain. Of course, this breaks down if you have code generated from templates, because the initial input is then smaller than the resulting source that needs to be maintained.
If you have a system where the default behavior is generally right, and where it's easy to get non-default behavior when necessary without losing the default behavior for everything else, then you can minimize the size of your code base, and therefore minimize your maintenence burden. My impression is that RoR takes pride in the brevity of the application, so there's got to be a certain amount of maintenence savings from this effect.
I think upper management directly correlates quicker turn out time to bigger profit. The less time it takes you to do the job the quicker you can proceed to the next. Especially the non-technical ones. The only analogy I can ever think of is the car. We can build a car in a week. But we'll spend the next 6 months trying to put doors, a windshield, a slurpee machine (yea if only managament had let us know ALL the specifications beforehand) etc. on while its rolling down the road.
*DrugCheese rants*
I think that the software development community would be better served by discussions of how to build more robust, flexible, and maintainable software (thereby driving down TCO), than by the endless discussions that we currently see about how to build it quickly.
.each(), does have that method indeed. And it works right away.
And this is where Ruby on Rails really shines. It's very common to write tests first and code later in Rails. This alone lowers TCO considerably. Also, fewer lines of code means it's easier to comprehend for others. It does help yourself, too, when you go back to that first piece of code you wrote six months ago.
I have found that my Ruby on Rails projects are more maintanable than my Java projects, not less. The language feels much more natural, literally everything is an object, iterators are built-in, which means any object that should have
And don't get me started on code blocks. Those are things of beauty. So all in all, I have found that Rails is more than worth the hype. It actually delivers in terms of flexibility and maintanability.
But I still think Fred Brooks's advice in The Mythical Man-Month is correct: plan to build the first version to throw away.
That advice was one of several recommendations that Brooks modified or abandoned in the 20th anniversary edition
Oversimplifying at bit, he now recommends an incremental, iterative approach to development where the design is modified by feedback from users.
He stands by his original insights that adding programmers to a project during development increases the time it takes and that there is no silver bullet to solve that problem. However, in the four new chapters added to the original edition, he acknowledges that a lot has been learned about software development in the last 20 years and as a result, it is much easier to get it right the first time.
People care a good deal less about maintenance cost than development cost because it is a future cost. Net Present Value discounts future dollars by whatever interest rate the organization uses for investment decisions. In practical terms, with a 10% interest rate (low by historical standards) a dollar of cost in 5 years is worth about $0.62 today. A dollar of development cost today costs a dollar. So while trying to optimize for TCO isn't stupid, it also isn't quite the win that most commenters seem to believe. As interest rates rise, as they must due to our incredibly irresponsible fiscal policy, there will be even LESS attention paid to TCO. Heh.
I've become a lot more passionate about maintainability since spending time working on a maintenance team. I go into this topic in more detail in a few of my articles: The Importance of Maintainable Software and How to Create Maintainable Software.
Also, in finance there is the "time discounting" principle, also known as "future value". Basically it says a dollar today is worth more than a dollar tomarrow. Thus, revenue generated soon is more valuable than revenue generated years down the road.
Table-ized A.I.
I've found that different developers often don't agree on what the pattern of future change will be. You cannot target future changes if you don't know or don't agree on what they are. People's experiences seem to leave them with different memories. They may remember X busting, but not Y busting. In other words, selective memory.
I've been in long debates where someone claims that Foo Oriented Programming is better for maintenence. But when I ask for example scenarios, they provide what seem to be low-probability scenarios. But they insist it is high in their experience. Thus, we are stuck at an impass. No coding technique or paradigm is a free lunch that optimizes for every change scenario.
In many ways it is like investing: *guessing* which paths are the best and putting your money on them. If it was a science, we would all be rich.
Predicting the future is still a subjective art. Their ain't no consensus magic formula.
Table-ized A.I.
The latter, which forces your code into an MVC model where database, mailer, and other underlying components are neatly isolated from the rest of the program logic, and the presentation templates are isolated from code receiving and processing user input
I have to disagree, or at least give a warning about this "separation" mantra. For many kinds of projects it is *unnecessary*. It creates two places that have to be changed instead of one. For example, if you add another column to the database and a report, then you have to go to the presentation side, and then go to the query side. You have to make two trips, and possibly have to also expand the interface between them for the new column.
If you had the SQL close to where it was used, then you would only have *one* change spot instead of three. Separation has tripled the cost of change in this case.
One of the justifications for separation is "what if we switch database vendors?". It happens, but does it really happen often enough to justify the "wrapping tax" (separation)? The wrapping tax is *always* paid whether you use it or not. But the benefits of wrapping for swapping are only collected *if* you switch vendors.
If you really switch vendors that often for custom software, then something else is probably wrong. Plus, it is a one-time change for the most part. You spend a day finding and changing the SQL, and then it is mostly done. (Testing has to be done in either case.) It is not something that anchors you down year in and your out like the wrapping tax does.
Table-ized A.I.
Smart programmers know that management is never as smart as they think they are (hell, for that point the programmers know that about themselves as well;) You're wasting time on requirements when you spend 3 months producing a dead tree in a binder that's already inaccurate. Spending weeks agonizing and planning for things that may never happen to the point that you can't ship anyting of value to anyone is wasting time. As far as management knows, sometimes there's no clue to be had or they get the wrong clue. Even if management knows exactly what they want, it may not be what is needed.
There are things you know that you know, things you know that you don't know, and things you don't know you don't know. Or: known knows, known unknowns, and unknown unknowns. The only value lies in going after the first for the three. The rest will change for certian. Hell, sometimes the first changes (e.g. they were wrong).
As far as "just write some code". Sure. As long as it's meeting the most important business requirements, you can get feedback, and you take the time to build in quality w/ test coverage: absolutely! That is however different thatn "just hack something out"...
*** Sigs are a stupid waste of bandwidth.
"I think that the software development community would be better served..." By better served, do you mean as in producing a better product, or as in job security?
The biggest problem is there is buy in by PROGRAMMERS (the professionals who are suppossed to know better) that the TOOL MATTERS.
This is simply not true.
Study after study has shown that when talking about anything that matters (does the delivered solution resolve the problem, is the cost of delivery of a working solution in line with the intial budget estimate, TOC, etc.) the tool is irrelivant to the discussion.
What is relivant is if the system is architected well. Is the problem fully and completely defined? Does the scope remain stable over the development cycle (be it 2 week extreme thing or 5 year traditional thing) and is everyone coding to the same target? Is there a good communication plan in place for the project? Are all the developers using the same methodology and coding standards? Is there sufficient Q/A as part of the project plan to actually find the bugs that matter?
All of those, and many other items, matter.
But the very first discussion most programmers AND PHB's have when they decide to embark on a project isn't about problem definition, it's all about what tool to use.
Some day people will figure out that not only doesn't the tool matter, but that choosing an older tool means you can make use of deeper experience pools as well, which in some cases may be far more beneficial than being able to hire the cheapest programmers because everyone only has 1 year or less experience in the language because it's only a 1 year old language . . . (not to mention the problem young tools tend to have in terms of their own bugs and issues compared to older toold).
Software can be modifed, expanded, and built on very easily. Bridges cannot. You can make a simple form of your software, and then when the core is done, add in the additional stuff as you go. Having to rewrite sections here and there because things work differently than you thought is not the end of the world. Using a decent language, and assuming you aren't retarded, you can re-write the portions that need re-written in less time than trying to plan it out in the first place. And no matter how much time you waste planning it out, you will never get a full spec, with all the details needed, so you will still have to go in and change stuff when the client sees it anyways.
Or do you think that it doesn't count because it's run by Jews? Take your anti-semitism elsewhere, please.
No, it doesn't count. I'm talking about a democracy run by Arabs that can serve as an inspiration to other Arab countries to change their systems of government.
Re: "Also, it may be more code between of the code for the interface between the SQL and the method body that uses it."
Corrected: Also, it may be more code because of the code for the interface. That is the interface between the SQL and the method that uses it. Example:
Together:
sql = embed("select....where x=? and y=?", foo, bar);
result = execSql(sql);
Together adding another parameter:
sql = embed("select....where x=? and y in (?,?)", foo, bar, zak);
result = execSql(sql);
Separated with 2 parameters:
result = execSql(getSqlA(x,y));
stuff...
function getSqlA(foo,bar) {
return embed("select....where x=? and y=?", foo, bar);
}
Separated with 3 parameters:
result = execSql(getSqlA(x,y,z));
stuff...
function getSqlA(foo,bar,zak) {
return embed("select....where x=? and y in (?,?)", foo, bar, zak);
}
(I didn't include sql injection protection here to keep the examples simple.)
With separation, I had to change three statements, whereas I only had to change one when not using separation.
Table-ized A.I.
In project you got scope, cost and time, right? When calculating these, you calculate them for the project. If say you will do it fast and cheap, the project gets approved. At least internal software gets developed as a project and for the project you get some budget. Who cares for the operating cost?
I don't harbor any suspicions that fads will stop being popular ... but why anyone would want to use a brand-new language to do something serious???
"Faster". Uh-huh. That's sort of like saying that nuclear power is clean.
Franklin said haste makes waste. Programming is proof of that. Good code is a joy forever. Junk bonds earned their name.
"You must try to forget all you have learned. You must begin to dream." -- Sherwood Anderson
Since we are down 3 bodies in the total DBA group right now, and I am trying to handle the job of what was 3 DBAs while we hire new ones, then what do you think?
Besides, I have seen the developers working on it. It isn't saving them any time, and the software is no better than without rapid development.
Net loss, you better believe it.
How do you know you are building in quality? How do you know your unit tests are really covering real customer situations? What is the motivation for your average programmer to do any of this? Why put in the effort if management doesn't know the difference? BTW - I agree with all your points, if we agree on what market you are in. But - I seriously doubt that any programmer knows more about what the market needs, than any reasonably competent manager - if that isn't an oxymoron. I *have* worked with one or two reasonable managers in 35 years of doing this. Hell, I used to be one. At some point, you *have* to drink at least a tad of the kool-aid, from *someone*, just to stay sane and believe that you are contributing. However, if your goal is to satisfy *yourself*, then all bets are off. In the world of business, that's absolutely the wrong goal.
Mediocre programmers use UML and design to look productive and to have a reason to exist.
Mediocre companies made of mediocre employees pays thousands of dollars for advanced design tools but the code will suck eventually because the programmers suck and there will be bugs and security flaws and a bunch of whiners pointing fingers at each other for their own mistakes. In an attempt to fix these flaws they will undo all their design and resort to spaghetti code.
Disclaimer: I am an agile fanboy/advocate and I do XP. My team follows all the major controversal practices (pair programming, Test Driven developent, continuous integration, short iterations). The motivation for the average programmer is two-fold: test coverage builds confidance in both you and your code base, and spending time writing tests to think about both what you're doing an how you do it makes you become a "better than average" programmer. You know you're building in quality when you go to change something and you predict where tests will break (and they do). You know if you're missing quality when you find a bug, write a test that fails (which describes what the code should NOT do) and then you fix it, thus raising your quality. As for covering real customer situations, unfortunatly there's only one way to address it: you MUST talk to them directly! No matter what SDLC/CMM/Agile/ProcessD'Jour you follow, you won't ship jack that works untill that happens. There's a joke that the next hot new Agile methodology will be XTTAFC (eXtreme Talking To A F*%king Customer). I'd love to see it start to catch on...
My sales pitch goes like this: XP and agile methods are no Silver bullet, but they are a nice collection of wolfsbane, garlic, holly water & crucifixes;) You're not going to kill the monster, but you're much better equipt to make sure you don't get dragged away...
*** Sigs are a stupid waste of bandwidth.
Because code should be 90% planning, 10% work.
I'm god, but it's a bit of a drag really...
Moving into management to reduce the number of inept managers DOES work. I did it a few years ago, and I haven't looked back.
Tis a far, far better thing I do . . . .
-- If you're posting to be funny, and your sig is funnier . . . .
I agree that TCO is more important than just rapid development. Its too early in Ruby on Rails for me to say based on experience if ROR will actually lower TCO. However, based on the development we've done so far, here's why we think it likely will: 1. We have a simpler relationship between the front & back end due to Active Record, so this should save time in adding or deleting database fields. 2. The total amount of code is about 1/10th what we had in .NET and its very easy to read, which should cut the learning curve of new developers who have to maintain the project over time. 3. The "Ruby on Rails" framework itself forces structure and makes it a bit harder for each developer to create an idiosyncratic piece of code, that no other developer is likely to understand. 4. The Ruby on Rails community seems to be a high proportion of very high end programmers who document many component solutions to common coding issues in a really deatailed way that has made it very easy to Google these solutions and incorporate it into our code. It seems to be another level of "Open Source" mentality beyond what we've seen in other open source platforms. The quality of the open source components so far has been consistantly high. The self documenting feature in Ruby on Rails also should lower TCO.
-Paul Levy
www.deepvertical.com
In the era just before the current one, the accepted wisdom was to spend lots of time on requirements, design, code, and test in order to save lots and lots of money on maintenance. But since development took so long, many projects ran out of money before producing any software. And those that did produce SW didn't provide what the customer really wanted.
So some of the gurus of the SW world decided it would be better to develop quickly and at least get something done, and get some feedback from the customer before spending too much time and money.
Maybe the pendulum will swing the other way now.
I think the reason we are seeing these quick delivery of applications is not for first mover advantage but more... people do not know how other people are going to react to the software they have built... the feedback given once an application is live is much more important than being first advantage... think about google... think about netscape... think about msft... they all release code that is hard to maintain... that is riddled with holes... because there is no way to really assess the success or failures of a product until it is in front of the users... this feedback then gives you the next steps on what you will need to build/fix/rewrite etc... so the rapid development abilities are important because they give us a way to capture the requirements of an application...
>A complex software project doesn't compare well to a bridge. It's more like a city. Nobody goes and says
>"Let's build a city!", lays out plans, prototypes and discusses what business go where.
Yes, actually, they do. If they didn't, cities would be unliviable shitholes, where it would be impossible to get from point A to point B, or to hook up power and water, etc. Sometimes people even tear down large sections of a city, once they've gotten out of control and don't fit into a coherent design.
What you are describing sounds more like a refugee camp than a city.
Now, it doesn't make sense to document and plan around things you don't know, but all kinds of engineers from software developers to civic engineers must plan around the knowns and create a framework that the unknowns can be made to fit within.
If your software will need to be expanded in the future in ways you can't predict, that's not an excuse for writing throwaway software now. If possible, you must design your software so that it is flexible enough to be reused in new contexts. You must take care to keep the parts loosely coupled, so that if some parts may be redesigned, the remaining parts can be left the same and reused.