Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Best Programming Practices For Web Developers

kdawson posted more than 6 years ago | from the using-hard-won-knowledge dept.

Programming 210

An anonymous reader writes "Web pages have become a major functional component of the daily lives of millions of people. Web developers are in a position to make that part of everyone's lives better. Why not try using traditional computer programming and best practices of software engineering?"

cancel ×

210 comments

Sorry! There are no comments related to the filter you selected.

More than one side to this one... (5, Interesting)

fyngyrz (762201) | more than 6 years ago | (#20536135)

Best programming practice is to do everything server side and not hijack the CPU of the site visitor; not depend on client-side active compatibility (for instance, just tried to pay for an EBay auction today, wouldn't work, don't use Explorer...) if you do server side processing, you can make it work for *everyone*. That alone is enough reason to go for it. Then there's Digg; Digg's pages are such a load on the visitor's CPU that I have to click "script not responding, continue?" three times on a page with 800 or so comments with Firefox and a dual-core 2 GHz CPU just to get the page to completely render. Sure, some of this is junk programming, not junk technology, but even so, if the server was doing the work of formatting (like it traditionally has here on slashdot), then it'd just be a matter of my browser reading HTML, instead of trying to run other people's scripts locally. I'd give up the web 2.0 "candy" in a second just to have a reliable web page.

Sadly, I know people will typically go for glitz over functionality, so the only thing that will kill web 2.0 is web 3.0, and I have little doubt it'll be even worse. :(

As for leaning towards good programming practices, my suggestion is to start by taking PHP off your server, learn Python (or Perl if you're feeling feisty) and write something that at least has a chance of being reasonably structured. Keeping in mind I'm a huge fan of Python.

Re:More than one side to this one... (2)

timmarhy (659436) | more than 6 years ago | (#20536165)

Agreed on all counts. stick with serverside processing and you'll have a faster, better webpage. At the end of the say all the pretty scripts and flashing buttons don't mean jack if the site doesn't run properly.

look at /. and compare it to digg, that's all you need to show anyone to convince them i think.

Re:More than one side to this one... (5, Informative)

tajmahall (997415) | more than 6 years ago | (#20536375)

Actually when /. articles have 700 comments or so I need to answer the "script not responding" error message several times.

Re:More than one side to this one... (5, Insightful)

Eivind (15695) | more than 6 years ago | (#20536909)

That's almost, but just almost, true.

Thing is, serverside can be made to work for everyone, which is a plus. But the flipside is it can be *slow* for everyone, because serverside you often have no other choice than redraw the entire page (which can be expensive sometimes) even for a tiny change.

So, the way we tend to do it is graceful degradation.

If there's something to click on that'll rely only change a small part of a big page (say clicking a link to expand a comment-tree) this is what will happen:

The link is a normal a href= link, fully standards-compliant, should work even in ancient lynx.

We then use a standards-compliant well-documented library, jQuery, to add an onclick-handler to the link. The handler returns false, which supresses normal link-following for browsers with javascript turned on. The benefit is that those with javascript saves a lot of bandwith and time, they'll only load the ~500 bytes for the extra comment, not the ~20kb for the entire page.

The only way someone would be screwed with this solution would be if their browser *did* support javascript (and had it turned on), yet *wasn't* correctly supported by jQuery *AND* doesn't support the relevant standards for javascript. I am not aware of even a single example where this is true, if I became aware of such an example, a single "return true" for that browser would instantly enable all functionality.

Now, if someone has a browser with javascript, and with a faked browser-header so I can't tell it apart from browsers with a working javascript-implementation, and the javascript-interpreter doesn't understand standards-compliant javascript, then they're screwed. (well, they need to disable javascript to get the site to work...) but in that case they've spent rather a lot of energy for getting screwed....

I think this solution is a fair bit better than "only serverside everything" actually. But yeah, it is extra work, because you really offer both alternatives for these functions.

Re:More than one side to this one... (-1)

Anonymous Coward | more than 6 years ago | (#20536185)

I find the best programming practice is to not do any programming at all - instead, I have a number of immigrant families locked in my basement. They all have their own cheap old 386 pc on which they handle incoming requests manually. Some searching through an Excel spreadsheet, a bit of cut & paste in Notepad, and the HTML gets sent back out. Sure, its not very quick, but as long as you can afford some mouldy bread and water it scales very well indeed!

Re:More than one side to this one... (1)

Whiney Mac Fanboy (963289) | more than 6 years ago | (#20536187)

for instance, just tried to pay for an EBay auction today

What payment method? I buy ebay things all the time, using FF under linux - no problems at all.

learn Python (or Perl if you're feeling feisty) and write something that at least has a chance of being reasonably structured.

Reasonably structured perl? The mind boggles.

Re:More than one side to this one... (4, Insightful)

KiloByte (825081) | more than 6 years ago | (#20536385)

learn Python (or Perl if you're feeling feisty) and write something that at least has a chance of being reasonably structured.
Reasonably structured perl? The mind boggles.
In Perl, you can use exactly the same structures as in most other languages, as Perl, just like English, not just borrows constructs from other languages but assaults them in dark alleys to riffle through their syntaxes. You can write near-shell, near-C, near-AWK, near-sed, etc in Perl as much as you like. And unlike Python you can, you know, use indents to mark up the code instead of placating the language's wishes.

The only problem is, Perl allows insanely terse code. One line of Perl can often replace a page of C or five pages of Pascal. This is tempting, and it's easy to get hooked up and produce read-only line-noise. Yet, with a modicum of self-control you can write readable, well-structured Perl code.

Of course, this is just like writing secure code in PHP. It is possible, yet no one practices it...

Re:More than one side to this one... (4, Interesting)

SCHecklerX (229973) | more than 6 years ago | (#20537895)

Definitely. And because of this ability to adopt a particular style, Perl is the only language I know that I can walk away from for a year, and still be able to write a simple script without having to look at any reference material. If I ever have to do a comparison test in bash, I always have to dig up sample code to figure it out.

Re:More than one side to this one... (2, Funny)

emurphy42 (631808) | more than 6 years ago | (#20539341)

it's easy to get hooked up and produce read-only line-noise.
ITYM "write-only"

Re:More than one side to this one... (4, Insightful)

TLLOTS (827806) | more than 6 years ago | (#20536215)

I think you're making the same mistake that the numerous anti-Flash zealots make, and that is assuming that bad use of a tool equals a bad tool. Technologies like Flash and AJAX and all the other technologies surrounding and supporting them can add a great deal of value to a website, but only if done correctly.

Of course with the bar being set so low for getting started in website development it's no surprise that we see the horrible messes that we do today.

Re:More than one side to this one... (5, Insightful)

astrotek (132325) | more than 6 years ago | (#20536317)

The rules for a web programmer should be

1) DO NOT REINVENT THE BROWSER
2) DO NOT HINDER THE BROWSER
3) DO NOT TRUST THE USER

Re:More than one side to this one... (5, Interesting)

dkh2 (29130) | more than 6 years ago | (#20536453)

You missed one.

4) Do not use methods that are OS or Browser specific.

As for #3) - Absolutely true. Too many developers depend on sniffing the User-Agent string to determine browser capabilities. A much better, more reliable and easier to maintain approach is to test the specific capabilities you use, and provide a way for alternative access to the content. Note "alternative" != "100% equivalent."

Re:More than one side to this one... (0)

Anonymous Coward | more than 6 years ago | (#20537947)

1) DO NOT REINVENT THE BROWSER

While I agree that nobody wants to use your new, fancy way of navigating web pages (ie: Having those stupid Flash scrollbars instead of the browser's), there are things you just can't do (realistically) with today's browsers without resorting to Flash or heavy AJAX (some Intranet applications come to mind).

So you can either not create these sites/apps, or build them any way you can. Besides, I think that's part of how browsers evolve, by pushing these limits. Sure, many of these sites/apps are just junk, but there's a real legit demand for some of them, and they bring the issues to the surface.

Re:More than one side to this one... (0)

Anonymous Coward | more than 6 years ago | (#20539157)

So you can either not create these sites/apps
I'll take that one!

Re:More than one side to this one... (1)

Mr2cents (323101) | more than 6 years ago | (#20536417)

I think you're making the same mistake that the numerous anti-Flash zealots make, and that is assuming that bad use of a tool equals a bad tool.
Has flash been opened up yet? If not, that alone should be a good enough reason to dump it. Remember, the web is a standard. I could in theory design my own processor, make my own programming language, and use that to write my own browser to access the web. But if I need a supported platform to use flash, than it is useless.

Re:More than one side to this one... (2, Insightful)

TLLOTS (827806) | more than 6 years ago | (#20536491)

That's a rather narrow-minded way to look at it. Far better to gracefully degrade if the user doesn't have Flash than to say "well someone people might not have it, so it's useless!".

Re:More than one side to this one... (5, Insightful)

pedestrian crossing (802349) | more than 6 years ago | (#20536705)

Far better to gracefully degrade if the user doesn't have Flash than to say "well someone people might not have it, so it's useless!"

By gracefully degrade, do you mean "gracefully" putting up a banner that says "you need Flash to see the rest of this page"? Because that doesn't cut it.

Once Flash enters the picture, it either becomes necessary to have Flash to access the content, or it becomes obvious that Flash was unnecessary in the first place.

Very few designers use Flash to merely "enhance" a page. Flash invariably becomes necessary to access the page's core functionality. The "graceful" degradation usually follows a pretty steep curve (ie. all or nothing).

Re:More than one side to this one... (2, Insightful)

jefu (53450) | more than 6 years ago | (#20537823)

The problem is that the "designers" have often only learned flash, as they consider themselves "designers" and not "programmers" (who should know more than one language, programming techniques, how to debug and ...). They only want to "design" - pick their favorite fonts, make fancy navigation structures that look cool. They usually consider programming a bit icky and "right brain" (or is it "left brain"?) and somehow beneath them. Sadly, for many this attitude is taught to them in college (sometimes even by people in CS programs). Naturally, this is not true of all "designers" and the best either work hard to figure out how to do things well, or realize their limitations and use good programmers to help them.

Re:More than one side to this one... (1)

Skapare (16644) | more than 6 years ago | (#20536933)

Until technologies like Flash are made reliable and secure across all platforms, web developers ... don't have to stop using them, but ... really must take into account that some web users won't have the capability and they (the developers) need to provide alternatives, even if less glitzy. Things like don't make the whole content be in flash would apply here. Use Flash for what can't be done by other means. And make audios and videos available directly in standard formats.

Re:More than one side to this one... (4, Interesting)

skeeto (1138903) | more than 6 years ago | (#20538327)

anti-Flash zealots [...] assum[e] that bad use of a tool equals a bad tool

If 98% of the use of hammers was just to smash random things for no reason in particular, I would avoid being around people who owned hammers. I would probably call it a "bad tool" as well.

Re:More than one side to this one... (5, Insightful)

All_One_Mind (945389) | more than 6 years ago | (#20536255)

I disagree. I do web programming everyday, 8 to 14 hours a day. I do understand your point, but there's a time and place for everything, including client side scripting. There's a ton of stuff that can't be done on the server side, and the DOM is a wonderful thing to work with if you don't go overboard.


For example, I've written a few web applications per client spec that required various effects, animation, windowing, and tab features. These are all things which are better left to Javascript, and in my preference, the jquery [jquery.com] and interface [eyecon.ro] libraries. In fact, there's no real way to accomplish most of those effects without client side scripting. Hell, even Slashdot uses Javascript in their comment system, Firehose, etc. Or look at Google Apps, GMail, YouTube. Not even possible without client side scripting. A well programmed client side script (like anything Google's coded) runs great on even a 500MHz Pentium 3.


Anyway, my point is that while I can understand minimizing client side programming, it shouldn't, and can't really be avoided completely. I personally love mixing client and server side programming to draw out the strengths in both methods. Just because the idiots at Digg can't program, doesn't mean the whole thing should be thrown out.

Re:More than one side to this one... (1)

Hathor's Dad (983147) | more than 6 years ago | (#20536589)

I agree. Leave user things like a "date picker" and input macros to JavaScript but leave form processing to the server, you know the one you control & trust. Firefox has a plugin to alter GET and POST vars after the form is submitted & checked by JavaScript. Server does data stuff, browser does monkey see monkey do stuff.

Re:More than one side to this one... (3, Insightful)

Planesdragon (210349) | more than 6 years ago | (#20536937)

Server does data stuff, browser does monkey see monkey do stuff.
This kind of "you can have any color so long as it's black" thinking is why I had to suffer through a web form user-account system that told me "invalid password" ten times as I tried to guess what their specific rules were.

Make the user's browser guide the data, check the input once, and then send to the server. There, the server checks it AGAIN. That gives you a redundant check in case someone hacks your client-side script, and lets the non-hacker still get the benefit of an intelligent page.

Re:More than one side to this one... (1)

Hathor's Dad (983147) | more than 6 years ago | (#20536963)

I see your point but in the end it goes down the same hole...the sites I work with are more regimented that a user cannot cause unintentional errors (Recruitment sites).

Re:More than one side to this one... (1)

Hognoxious (631665) | more than 6 years ago | (#20539207)

This kind of "you can have any color so long as it's black" thinking is why I had to suffer through a web form user-account system that told me "invalid password" ten times as I tried to guess what their specific rules were.
I'd say the reason is that someone implemented a rule without either:
saying on the page what the rule is,
or
providing a link to said rule.

But I'm wierd like that.

Re:More than one side to this one... (1)

cs02rm0 (654673) | more than 6 years ago | (#20537455)

I agree. Leave user things like a "date picker" and input macros to JavaScript but leave form processing to the server, you know the one you control & trust. Firefox has a plugin to alter GET and POST vars after the form is submitted & checked by JavaScript. Server does data stuff, browser does monkey see monkey do stuff.

You should do both, so you've got security server side and so that users don't chew up your bandwidth or have their time wasted to find out they've entered invalid details.

Re:More than one side to this one... (2, Informative)

ortholattice (175065) | more than 6 years ago | (#20536831)

Or look at Google Apps, GMail, YouTube. Not even possible without client side scripting. A well programmed client side script (like anything Google's coded) runs great on even a 500MHz Pentium 3.

The one app where Web 2.0 shines is Google Maps. But Google has been phasing into other things where it is just not appropriate, making them bloated, slow, awkward to use, and even buggy where they weren't before.

Example: The new Google Groups is an abortion, replacing the older interface (which was already slower and less user-friendly than the simple, plain DejaNews it replaced, with bugs like overlaying ad text on top of posts) with something that is truly horrendous. Nothing is formatted right unless you're in full-screen mode, making copy and paste from a local editor inconvenient. False line breaks are inserted at column 69 (whatever happened to the old column 72 or even 80 worst case?), so I have to switch my text editor to column 69 wrapping just for Google Groups if I want my post to look halfway decent. Google has ignored the huge number of user complaints about the new format (including my own insignificant one FWIW).

I've switched back to a Usenet reader for regular newsgroups and am much happier. Unfortunately Google-only groups are becoming popular, forcing me to use Google Groups sometimes. This morning I must have spent 10 minutes futzing with a post to one such group due to my post being rejected because it somehow forgot I was logged in, then rejected because of a timeout, then... oops I forgot to wrap my text editor at column 69, so the post looked like crap with successive long and short lines and code formatting that was barely comprehensible.

Example 2: I've played with Google Analytics, but god is it slow. Finding out a referring page is often impossible because it strips off everything after "?" in the referring URL. Maybe managers with time to kill like its pretty interface, but just give me the quick and dirty output of analog (web server logfile analyser) and I'm much happier.

Re:More than one side to this one... (2, Insightful)

Skapare (16644) | more than 6 years ago | (#20536987)

I can still submit comments to Slashdot with Javascript disabled. Be sure your submission system works that way as well. Javascript can enhance, and should. Lack of Javascript should not disable. It is not required to submit a comment.

As for YouTube ... totally possible without Javascript, Java, or even Flash. True, it would not look so good and would be harder for some people to use. But the way they do it, it's a broken site altogether when these facilities are not usable, and that does not have to be.

There are many sites that do just plain stupid things with otherwise great tools, mostly because they use them the wrong way, or for the wrong purpose. One example is the use of Javascript to replace hyperlinks. That breaks tabs. Instead, the design should include a genuine hyperlink that is intercepted by Javascript if Javascript is enabled. Make sure every "link" on your site works when I press the middle button to open it in a tab.

Re:More than one side to this one... (0)

Anonymous Coward | more than 6 years ago | (#20537395)

... except that Youtube videos are flash videos???

Re:More than one side to this one... (1)

Snocone (158524) | more than 6 years ago | (#20538283)

... not on my iPhone.

Re:More than one side to this one... (1)

Hognoxious (631665) | more than 6 years ago | (#20537377)

I've written a few web applications per client spec that required various effects, animation, windowing, and tab features.
Requires? Really? I definitely call busllshit on the first two, unless it's a game.

Re:More than one side to this one... (2, Insightful)

Opportunist (166417) | more than 6 years ago | (#20536295)

Good in theory. In practice, you'll run into managers who get all psyched out at the idea of dumping the workload onto the clients, because they have to pay for the servers and if the servers don't have to do the work, they can handle more clients, while you don't have to pay for the clients, the customer does that.

It's not a new idea to shift the workload to the customer. The internet did it in banking (you're your own teller in online banking), shopping (you're basically your own bookstore clerk at Amazon, doing all the work from searching, ordering and with the review system it extends even to explaining and recommending), why should it be different on the technical side?

Yes, those pages tend to stink, for the reasons you outlined perfectly. But that's not what is actually wanted by the ones who decide to create those pages. You, as the developer and the user of the page, suffer from it. As a dev, you know it's crap but that's how it is to be done (and of course, despite the client having to render and calculate it, you have to find some crafty way to obfuscate the code so nobody can steal it, making the overhead even worse). As the user, you have to suffer from insane loading and rendering times.

But we save 100 bucks on the server!

psyched out? (1)

airdrummer (547536) | more than 6 years ago | (#20536761)

i think the idiom u want is "psyched up";-) and i think there are valid reasons to shift the load to the client: sorting tables, 4 instance...it's silly to make another db query to retrieve the same data in a different order.

Re:psyched out? (1)

Opportunist (166417) | more than 6 years ago | (#20538109)

I've seen managers beeng psyched up, down, in, out and I swear, even top, bottom, and very, very strange, too. They've rarely been charming, though. But ya know, some states are hard to come by.

Re:More than one side to this one... (5, Informative)

Isofarro (193427) | more than 6 years ago | (#20536327)

Then there's Digg; Digg's pages are such a load on the visitor's CPU that I have to click "script not responding, continue?" three times on a page with 800 or so comments with Firefox and a dual-core 2 GHz CPU just to get the page to completely render.

Sounds like Digg is attaching events to every show/hide link instead of using event delegation and using only one event listener. Browsers can't really handle hundreds of attached event listeners, it is a known performance issue.

Now using event delegation [scripttags.com] instead of attaching hundreds of events should definitely be in a set of web development best practices.

Re:More than one side to this one... (0)

Anonymous Coward | more than 6 years ago | (#20536779)

WTF? I thought I understood most of this stuff until I read through those examples. What the hell do YAHOO.util.Dom.addClass() and friends have to do with it? Seems the author mistakes a library API example for an example of event handling.

Wothless!

Re:More than one side to this one... (0)

Anonymous Coward | more than 6 years ago | (#20537303)

I don't use yahoo api and even I can tell what's going on. He's basically saying don't attach handlers to every element in the page that needs handlers, instead have an event handler fire every time anyone clicks anywhere, handle the click and determine whether you're supposed to do something with it. Of course I could be wrong, I glanced at it for like 10-15 seconds.

Re:More than one side to this one... (0)

Anonymous Coward | more than 6 years ago | (#20537489)

But you probably already understood bubbling. Here is a much better example. [usabletype.com]

Re:More than one side to this one... (2, Interesting)

jsebrech (525647) | more than 6 years ago | (#20536475)

As for leaning towards good programming practices, my suggestion is to start by taking PHP off your server, learn Python (or Perl if you're feeling feisty) and write something that at least has a chance of being reasonably structured. Keeping in mind I'm a huge fan of Python.

You can do any OO design in PHP5 just as easily as in Python. PHP is less constrained. It allows people to use bad designs because this allows hobbyists who haven't learned correct design practices to build things. However, even though PHP allows you to build bad designs, it doesn't require you. It allows you to do everything by the book.

The best programming practice for web applications architecture is to serve your target market. If the target market want glitz that requires flash, and doesn't care who that cuts out, that's what you deliver. The goal of the architecture is not to instill your own sense of right and wrong onto the user, it is to enable the user to do what they want to do with high performance.

Re:More than one side to this one... (0)

Anonymous Coward | more than 6 years ago | (#20536725)

You can do any OO design in PHP5 just as easily as in Python.

I take it you've not used Python then? How would you do co-routines in PHP? Decorators? Metaclasses? Things like DictMixin?

"OO design" is a lot more than grouping methods and member variables into a namespace and calling it a "class".

Re:More than one side to this one... (1)

Hognoxious (631665) | more than 6 years ago | (#20539261)

"OO design" is a lot more than grouping methods and member variables into a namespace and calling it a "class".
It is? Oh, bugger!

Re:More than one side to this one... (1)

dzfoo (772245) | more than 6 years ago | (#20536789)

>> However, even though PHP allows you to build bad designs, it doesn't require you. It allows you to do everything by the book.

But the problem is that the book is not that good. Its full of redundant library functions, with inconsistent calling and naming conventions, and a glossy invitation to do things cheaply and thoughtlessly.

Perl may allow you to do incredibly terse code, yes, but even when so obfuscated, it still entices you to follow a grammatically coherent structure, as it were. Howerver, most of the time, you end up writing code as you write an essay. Whereas PHP is starting to look like the Win32 API: a highly crufty battleground, where new ideas are thrown in just to fight it out with the old ones left by the previous participants.

          -dZ.

Re:More than one side to this one... (1)

umghhh (965931) | more than 6 years ago | (#20537561)

No amount of new shiny compilers, languages etc will help if you start project not knowing engineering basics.
part of those basics is review process:

1.design
2.review what you have done
3.if needed do rework and goto 2.
    else continue
4.write a report of finished work

That it is needed avoids many. Some even are delusional enough to believe that for instance outsourcing removes need for proper design whith result that they either lose customers, lose control or both.

There are (almost) no technical problems - quality is decided where budget and methodolgy is. Once these are screwed the product is doomed. From this perspective it is cheaper to skip/refrain from development instead of developing 'flowed by design products' that do not work anyway.

Re:More than one side to this one... (1)

bteeter (25807) | more than 6 years ago | (#20538625)

You had me until you said "taking PHP off your server".

Being a good Computer Scientist is all about applying sound principles and practices whatever particular problem your working on at the time. Some programmers blame tools and languages for their inability to use them well. (Kind of like blaming the hammer for smashing your thumb.) You _can most definitely_ code in PHP in a structured, easy to maintain way. I've done it, I've seen it done plenty of times. Same goes for Perl, Python, C/C++, Java, etc. Sure some may have better tools than others, but good code can be produced in all of them.

Some languages certainly have better tools, but programmers 30 years ago did just fine without all the wiz-bang development tools we have today. It just took a little more planning and effort - the two items that are lacking in most poorly written projects.

Avoid ASP is a good start. (0)

Anonymous Coward | more than 6 years ago | (#20536151)

See subject.

Avoid ActiveX is a better start. (0)

Anonymous Coward | more than 6 years ago | (#20536243)

See subject

"Good practice" is an outdated concept (4, Funny)

BadAnalogyGuy (945258) | more than 6 years ago | (#20536179)

The whole idea that you should design before implementation is laughable. So is the idea that programs should be built to last.

The program you write today will be tomorrow's cruft. Better to write cool, flashy apps that keep you at the front of the technology and let the monkeys in the basement cubes figure out how to keep your crap running. It's how you cultivate a good reputation for being a technology leader.

You only live once. Why waste that time writing good code that's going to be thrown out anyway? Write cool code that makes you look good. Make a lot of money and retire early.

Re:"Good practice" is an outdated concept (1, Funny)

Colin Smith (2679) | more than 6 years ago | (#20536209)

Sadly, please mod insightful.
 

Re:"Good practice" is an outdated concept (1)

Opportunist (166417) | more than 6 years ago | (#20536251)

Make a lot of money and retire early. ...and until you do, gives you total job security, since nobody but you can actually read the crap you wrote.

Oh yeah, those were the days at some large, German company. I heard they still use the crapola spaghetticodemonster I created. I really, really don't want to meet the maintainers and have to admit that I was the one creating it. That's something you usually get to see on Springer.

Re:"Good practice" is an outdated concept (4, Insightful)

Pike65 (454932) | more than 6 years ago | (#20536293)

Lemme guess - you're a contractor.

Unfortunately someone has to maintain your crappy code, and from my experience contractors all seem to be well aware that it isn't going to be them. We've stopped hiring contractors now, because frankly I'm tired of cleaning up other people's shit.

As to my advice:

- have a proper data layer (we codegen it using Entityspaces [entityspaces.net] )
- have a proper business layer (we codegen most of that too with Codesmith)
- it's a database, not a spreadsheet
- XHTML will make your life easier

Re:"Good practice" is an outdated concept (2, Interesting)

DangerJones (1125935) | more than 6 years ago | (#20536469)

I'm not a contractor - but I like his style.

I'm a web developer with a successful SAAS product in the market. It's a cool flashy app that's kept us at the front of technology. Yesterday I could have either built a new ajax graph widget for the front page - so we can win another client - or fixed the log in code so it stopped calling the database twice per log in and save me having to order another server.

Guess which I did? :)

There are more types of apps and development practices in heaven and earth, Pike65, than are dreamt of in your advice.

Re:"Good practice" is an outdated concept (2, Interesting)

Pike65 (454932) | more than 6 years ago | (#20536523)

I guess that's what really grates on me.

You tell a client that they need to pay for a new server and they're fine with that.
You tell them that they can pay you 30 developer-hours to fix some issues so they won't need the new server in the first place and they act like you're trying to rob them.

Re:"Good practice" is an outdated concept (1)

SatanicPuppy (611928) | more than 6 years ago | (#20537689)

I don't know about you, but 30 hours of my time would buy a hell of a server.

Anyway, you have to sympathize with their desire for something tangible. If anyone ever asks them to cost justify a server, they can take that guy into the server room and point to it. If someone ever asks them to justify the code...Well, that gets ugly. "We had to fix the code." "O Rly? Why didn't it work right in the first place?" "Well, it did, but..." "So you gave the same people more money?" "Uhh, well, other people would have cost..." Etc, etc, etc.

I used to do consulting where I cleaned up existing monstrosities, made them maintainable, etc. When you do that kind of work, you ask for your money up front, because as soon as they start code auditing and find out that you reduced their codebase by 40% they lose their minds, because the metrics they use to put that crap in the budget don't account for "negative work".

Re:"Good practice" is an outdated concept (1)

Mipoti Gusundar (1028156) | more than 6 years ago | (#20539309)

I don't know about you, but 30 hours of my time would buy a hell of a server.
Sir, 30 hours of my time would barely buy a servING of yur most delicius freedom fries.

Re:"Good practice" is an outdated concept (1)

oliverthered (187439) | more than 6 years ago | (#20538119)

now all you have to try and do is keep your customers happy even though you've got a flaky product.

Re:"Good practice" is an outdated concept (0, Flamebait)

Hathor's Dad (983147) | more than 6 years ago | (#20536623)

"We've stopped hiring contractors now, because frankly I'm tired of cleaning up other people's shit." Sorry the Romans are on the phone and are wondering if .....never mind. Hey you work in X you clean up the Y of the X that went before you.

Well, it does make me wonder, though (5, Insightful)

Moraelin (679338) | more than 6 years ago | (#20536367)

Well, you bring an insightful point into how that goes downhill, but that's exactly what makes me wonder.

Engineering used to be about starting from a problem and figuring out the best solution. Well, best within the limits of your knowledge and abilities.

E.g., let's say you have to get people from A to B across a river. You'd start from that problem and figure out a solution, and not from "but I wanna build a cantilever bridge, 'cause it's the latest buzzword" and find a river in the middle of nowhere. Or dig a canal if you don't have a river for your buzzword bridge.

Then you'd look at the exact data your problem is based on. How wide is that river? What kind of traffic you expect over it? Is there barge traffic on the river that you'd have to deal with?

Then you'd look at the alternatives: do you need a bridge? Maybe a ferry is enough? How about a tunnel under it? If you decided on a bridge, should it be cantilever, suspension, or what? There is no free meal. Each option has its own advantages, but, and here's the important part, also its disadvantages and limitations.

And I think that's exactly what's missing in most of "software engineering" today. People start from what's the latest buzzword, and then work backwards to try to find some problem (even imaginary) to apply it to. They'll build a bridge in the middle of nowhere, in the style of 19'th century follies, just because they want a cantilever truss bridge, everything else be damned.

(Except the 19'th century follies were actually known to be follies, and built as a fucked-up form of social security in times of crisis. The laissez faire doctrine said that it's wrong to (A) just give people unemployment benefits, since supposedly that would have turned everyone into parasites, and/or (B) to use them to build something useful, since that would have competed with private initiative. So they built roads in the middle of a field, towers in the middle of nowhere, etc, instead. Whereas today's programs don't even have that excuse.)

And while it's fun to blame monolythic programs written by monkeys, I'll go and blame the opposite too: people who do basically an overblown cargo-cult design.

(Cargo cults happened on some islands in the Pacific when some supplies were supposedly paradropped to troops fighting there, but instead landed on some local tribe. The aborigines then proceeded to worship the big birds that dropped those, and pray that they come drop some more of that stuff. And when they didn't come back, they sculpted airplanes out of wood, and kept hoping that those'll drop some food and tools.)

People who don't understand what a singleton, or a factory, or a decorator pattern, or a manager pattern are, or when they're used, go ahead and created tons of them just because they got told that that's good programming practice. Everything has to go through layers upon layers of decorators, built by a factory, which is a singleton, registered with a manager, etc. They don't understand what those are or when or why they're used, so they effectively went and sculpted their own useless wooden factory, like the tribes in the Pacific.

So maybe just telling people about some "best practices" isn't everything. Some people _will_ manage to turn any best practice into the worst nightmare. Maybe what's really needed is to remind more people what engineering used to mean.

The same goes for design before implementation. There are places which sanctified the worst caricature of the waterfall model, but again, in a form that actually is worse than no design. Places where you have to spend two years (don't laugh, I know of a team which had to do just that) getting formal specs out of every single user (who hasn't even seen a mock-up yet, and some don't even understand what the techies actually want), then have an architect design an overblown framework that does everything except what the users actually wanted, then get on with the coding, then they have 1 month allocated for tests and debugging at the end (which won't be enough), and only then the client actually sees anything and discovers that that's not what he meant. Or that in all that time, the process already changed twice.

As a painful example of non-techie users getting confused while having to explain every nut and bolt in advance, take the following funny example: the above-mentioned team had, among other monstrosities, the requirement that a form has to be saved in the database each time the user leaves a field or switches tabs on a tabbed pane. So they go through the whole implementation and testing with that, then the users complain (quite justified) that it's so slow it's useless. Turns out that the guy with that requirement didn't actually mean that, and didn't even understand enough of databases and apps to make that kind of a call. He just wanted that the data doesn't disappear from his form when he switches tabs. I don't know why and where he got the idea that it would. Maybe he was thinking of web apps where the data can disappear if unsaved, when you move to another page.

Re:Well, it does make me wonder, though (2, Informative)

nospam007 (722110) | more than 6 years ago | (#20536531)

(Cargo cults .....The aborigines then proceeded to worship the big birds that dropped those, and pray that they come drop some more of that stuff. And when they didn't come back, they sculpted airplanes out of wood, ....
---
Actually they did the _airport_ (not the planes) out of wood and straw, complete with tower and offices.
They wanted to attract the planes.

from Wikipedia: ...
Famous examples of cargo cult activity include the setting up of mock airstrips, airports, offices and the fetishization and attempted construction of western goods, such as radios made of coconuts and straw. Believers may stage "drills" and "marches" with twigs for rifles and military-style insignia and "USA" painted on their bodies to make them look like soldiers, treating the activities of western military personnel as rituals to be performed for the purpose of attracting cargo. The cult members built these items and 'facilities' in the belief that the structures would attract cargo. This perception has reportedly been reinforced by the occasional success of an 'airport' to attract military transport aircraft full of cargo...

Re:Well, it does make me wonder, though (1)

TheDugong (701481) | more than 6 years ago | (#20536673)

Depends which cult. The John Frum cult on the island of Tanna in Vanuatu did/do the runway thing.

However, look at the, now defunct, office cargo cults from this perspective:

Stone age Papua New Guinean sees fantastically wealthy - to a hitherto unknown level - white men arrive. His people have already figured out that they are not gods, but merely men with white skin. He takes notice of the fact that the white man sits in an office all day doing no more than passing paper around while the black fellas do all the work and do not get anywhere near as rich. He comes to the conclusion that the way to riches is to create an office and pass paper around.

How much of a modern western economy is based on shuffling papers? The right papers in the right order, but shuffling papers no less.

Re:Well, it does make me wonder, though (1)

Hathor's Dad (983147) | more than 6 years ago | (#20536649)

Engineering used to be about starting from a problem and figuring out the best solution. Well, best within the limits of your knowledge and abilities.

That is exactly what is required to innovate. Looking at solved problems does not make one engage at solving the problem themselves. People cry don't reinvent the wheel but then wonder why the prodigy of that idea have no idea what a spoke is.

Go invent your own wheels!!! There is much to learn, much knowledge to enjoy. Do it for yourself. Do it because you want to. Don't reach for the wheel.

Re:Well, it does make me wonder, though (0)

Anonymous Coward | more than 6 years ago | (#20537071)

Oh....my....god. Let me see if I can hit this nail on the head.

You LOVE UML.
You hate computer science majors.
You are a rocket scientist...seriously.
You love Java but seem to write most of your stuff in C#.
You hate Microsoft Visual Studio yet you still use it.
You talk to students like they are idiots.
You collect cookie fortunes and comics (...boring).
You used to sing until you realized a pizza could feed a family of four while you couldn't.
You went back to college, became an engineer, and have yet to get off of your high-horse since.
You are from a German decent.....remember at Deer Park?

Re:Well, it does make me wonder, though (1)

bobetov (448774) | more than 6 years ago | (#20537603)

And I think that's exactly what's missing in most of "software engineering" today. People start from what's the latest buzzword, and then work backwards to try to find some problem (even imaginary) to apply it to. They'll build a bridge in the middle of nowhere, in the style of 19'th century follies, just because they want a cantilever truss bridge, everything else be damned.

The main reason I use the same set of tools for each project I do, to the limit of my ability to do so, is not because it's flashy, but because the code I've written and used before is far more trustworthy, and faster to apply, than a new from-scratch solution.

You'd see an awful lot more of the kinds of behavior you're attacking if engineers building bridges could, freely and quickly, clone an actual bridge. Code re-use is a very good idea, and so the fact that I use fancy widgets a lot has more to do with my having fancy widget libraries that I trust than that I love fancy widgets per se.

I guess I'm just frustrated by the inevitable comparison between software design and other real-world engineering design. The domains have very, very little to do with one another. Analogies between the two realms rarely add value to the discussion, IMHO.

Re:Well, it does make me wonder, though (1)

Hognoxious (631665) | more than 6 years ago | (#20538703)

There are places which sanctified the worst caricature of the waterfall model, but again, in a form that actually is worse than no design.
Holy false dichotomy, Batman! While it's impossible to pin-down 100% of the requirements in advance (the so-called BDUF methodology) that doesn't mean you shouldn't be aiming at 90%, or that 0% is ideal. Let's say we were building an accounts system. It'd be good if we knew in advance whether it had to cover sales, purchases, or both.

the requirement that a form has to be saved in the database each time the user leaves a field or switches tabs on a tabbed pane
That's not a requirement. It's a method of implementing one.

He just wanted that the data doesn't disappear from his form when he switches tabs.
That's a requirement.

If you let the users do detailed technical design you're hosed before you start. I could tell a hundred war stories about this. They rarely if ever have the knowledge or skills - but often think they do. They should be specifying what, not how.

Sadly (1)

achurch (201270) | more than 6 years ago | (#20536577)

I've had people seriously make that argument to me. Whatever happened to pride in workmanship?

Re:Sadly (1)

BadAnalogyGuy (945258) | more than 6 years ago | (#20538783)

If I get paid the same whether I paint No. 5, 1948 [wikipedia.org] or the Sistine Chapel [wikipedia.org] , it only makes sense that I would put the minimum amount of effort into the work before moving on to the next project.

You ask "whatever happened to pride in workmanship". The answer is that each individual accomplishment is a source of enough pride to carry me over to the next lucrative job.

You can spend each day contemplating whether tempra is a better medium than oil-based paints, but I'll be splashing buckets of paint onto canvas and taking a tidy profit from each "exertion" while you're still counting the number of camel hairs on your brush. There's a place for both of us in this world. Mine is in the here and now. Yours is in the long-term historical record. When I'm dead and gone, you can have the last laugh. Until then, let me snort my cocaine off supermodel bellies in peace.

Why not? (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#20536191)

Because 94% of "web developers" are drooling script kiddy morons.

Not news (0)

Anonymous Coward | more than 6 years ago | (#20536195)

"Why not try using traditional computer programming and best practices of software engineering?"

By now, this is -- or should be -- common practice.

Productivity vs. The Right Thing (4, Insightful)

Max Romantschuk (132276) | more than 6 years ago | (#20536217)

Most web developers I know (myself included) have a fair idea of how to do things well. But most web development is project-driven, and once the page/site/app looks and works OK telling management that you need an extra week to refactor things isn't necessarily feasible.

That being said, we all know what happens to maintainability of a big project if done the fastest way possible...

Damned if you do, damned if you don't.

Re:Productivity vs. The Right Thing (1)

siyavash (677724) | more than 6 years ago | (#20536249)

I second that, it's very true. Sadly, a week extra for doing better code is not doable for all projects. They usually want the project out the door "yesterday" :(

Re:Productivity vs. The Right Thing (3, Insightful)

Opportunist (166417) | more than 6 years ago | (#20536265)

Actually, worse than that. You have it designed, created, streamlined and finished, all the while management tells you during reviews it's fine and exactly what they want, then, as soon as it's done, they want it upside down and inside out, and you get a few hours to basically rewrite it all because "It's all allready there, how much work could it be to do the few adjustments?"

And this is where it starts to get ugly.

Re:Productivity vs. The Right Thing (0)

Anonymous Coward | more than 6 years ago | (#20536269)

yeah. the poster is absolutely right about writing scripts that are processed on the server. Just like this site i developed http://www.ebuynigeria.com/ [ebuynigeria.com] which is totally server sided.

XSLT! (1)

Toreo asesino (951231) | more than 6 years ago | (#20536239)

Good article, but it doesn't mention anywhere XSLT - quite a major "step" in the giant layered cake that is web dev....which is basically from the bottom:

DBMS + Server-side code, XML, XSLT, HTML/Javascript, CSS

Xslt takes all the need to program & process display logic out of the server-side code, and is completely language independent - making it highly portable. It rocks when you know how to control the beast. You don't even need a server to run it - every browser since 1995 is capable of doing XML+XSLT client-side, meaning a whole chunk of "code" can be cut out from core development.

Re:XSLT! (1)

Anonymous Coward | more than 6 years ago | (#20536301)

XSLT isn't 'language independent' -- it's a language. In XML.
Sheesh, Java developers...

Re:XSLT! (4, Insightful)

mcvos (645701) | more than 6 years ago | (#20536449)

Xslt takes all the need to program & process display logic out of the server-side code

XSLT should only be used to transform backend XML into different XML or HTML. It should not be used for any kind of logic, processing, etc, because it doesn't perform nearly as well as a real programming language, and becomes very unreadable as soon as you deviate from simply applying templates and doing straightforward transformations.

I program in XSLT every single day, and I use a framework (Apache Cocoon [apache.org] ) that is basically designed around XSLT transformations, and the most common problems I see, are caused by people trying to do complex stuff in XSLT. XSLT is really great. Really. But it's no substitute for Java.

Re:XSLT! (1, Informative)

Anonymous Coward | more than 6 years ago | (#20537253)

every browser since 1995 is capable of doing XML+XSLT client-side

Really? Browsers have supported XSLT since four years before it was standardised (and three years before XML was standardised)?

Theres only one programming practice : (2, Insightful)

unity100 (970058) | more than 6 years ago | (#20536263)

1 - Do whatever your client wants you to do.

there is no 2. thats that. your client is your software development customer if you are self-employed or working as a lead developer in a software house, and your client is your superior if you are a programmer employee.

each and any other practice are only valid when you are doing your own personal projects.

Re:Theres only one programming practice : (1, Insightful)

Anonymous Coward | more than 6 years ago | (#20536351)

1 - Do whatever your client wants you to do.

there is no 2. thats that. your client is your software development customer if you are self-employed or working as a lead developer in a software house, and your client is your superior if you are a programmer employee.

each and any other practice are only valid when you are doing your own personal projects.
Clients often have only a limited idea of what problems are connected with a certain development approach. Letting a totally clueless client micromanage the way you implement a solution is a recipe for disaster. In the end it is your role as a developer/engineer to criticize what the client wants you to do and if necessary point out better and more efficient ways of accomplishing it than the methods your client has in mind. In the end you are going to have to put this project on your CV, so a failed project that results in a bad product isn't just your client's problem it is also your problem because to some extent it reflects on your competence as a developer. Personally I'd rather bail from a project that I can see is going really badly than to stay with it to the end and have to explain why it crashed and burned when I get asked about it on my next job interview.

Re:Theres only one programming practice : (1)

unity100 (970058) | more than 6 years ago | (#20536591)

youre right from tip to toe, but, its the client. rather stay with the project and explain stuff than leave them halfway.

Re:Theres only one programming practice : (5, Insightful)

rucs_hack (784150) | more than 6 years ago | (#20536405)

Nice idea. Unfortunately, clients do not always know what they need. They usually have an idea of what they want, but not how best to achieve it.

If asked about the development process they want, most would say 'fast and cheap'. Bearing in mind that a less than perfect website that is up and gaining revenue is better then a wonderful, fully featured website of d00m that won't be ready for six more months. A good programmer should advise the smallest possible feature set at first, so that can be tested, and decisions made as to the best way to proceed.

Besides, a cheap website can be improved over time, an expensive one that looks nice but doesn't quite do the job (find me a version 1 of anything that did) is costly even if all you do is remove stuff you paid a lot for.

Re:Theres only one programming practice : (2, Informative)

apt142 (574425) | more than 6 years ago | (#20537153)

Agreed, I find it is much, much easier to do small incremental updates and gains than to do the big website of d00m. Chances are, if you work with a customer and get the that version 1.0 up and running well, they'll look at you to do more for them. It is so much easier then to kick into incremental updates. Do small but functionally significant improvements.

Going from version 1.0 to 1.1 is much easier than from 1.0 to 2.0. And there are added benefits.

  • Since the changes are so small it's easy to explain what is covered in the scope of the change and what you can promise in another change. This keeps yourself from getting derailed by "new shiny's".
  • Not doing a lot of change all at once lets the users get trained to the new functions without getting overwhelmed.
  • As a developer you'll be forced to think more modularly. Which in my experience has been a very good thing.
  • The changes will be able to be done very quickly. So, the managers see progress, the company sees improvements.
  • Having the small projects lets you reorder them by priority and gets you a flexible long term plan.

Re:Theres only one programming practice : (4, Insightful)

simong (32944) | more than 6 years ago | (#20536571)

Not true. Take your client's requirement and interpret it in according to standards and best practise. Your client has hired you for your skills so it's your duty to do it properly and make it easy to update in the future if it's you who has to update it or someone else. Anyone can design a web page and far too often it's obvious that anyone has.

Re:Theres only one programming practice : (1)

unity100 (970058) | more than 6 years ago | (#20536707)

everyone does that. however client has the last word.

Re:Theres only one programming practice : (3, Insightful)

someme2 (670523) | more than 6 years ago | (#20536575)

1 - Do whatever your client wants you to do.
Yes.
Elaboration:
  • Define an appropriate granularity of your actions that you expose to the client.
  • Ensure that each action block results in something the client wants.
  • Do not do whatever your client wants you to do inside of an action block.
  • In time & material based projects an action block length may be atomic (client advises you on microscopic action, e.g. client says: Now press return. Now write 10 ?"Hello World").
  • In fixed price projects action block lengths can be defined by milestones (possibly with deliverables). Communication during action blocks may be a matter of tactics (e.g. misrepresenting project state as better or worse than in reality if necessary).
  • Client triggered course changes during action blocks in fixed price projects result in billable change requests.
Or something to that effect...

Re:Theres only one programming practice : (1)

TrappedByMyself (861094) | more than 6 years ago | (#20537045)

I'm pretty sure you didn't understand TFA

I am pretty confident.. (3, Insightful)

daydr3am3r (880873) | more than 6 years ago | (#20536355)

..that a vast majority of all we see on what's out there and instantly disregard as bad practices, are the result of pressure from marketing, management, corporate interests, politics, whatever you may call it, applied to a skillful and knowledgeable handful of people that had the mischance of being skilled at their craft, but powerless to make a stand on what is best and more efficient for the actual code and most probably, for the actual target audience. Of course that applies to any product, commercial or otherwise, being created by the ones who have the expertise but controlled by the ones who are considered managerial staff and probably know next to nothing about the product in question. Can you make it great? Perhaps you can. Do you have sufficient time/permission/resources to do that? Well then, that's probably not up to you now, is it?

Misleading question (5, Insightful)

suv4x4 (956391) | more than 6 years ago | (#20536387)

"Why not try using traditional computer programming and best practices of software engineering?".

Did you see the straw man? The question assumes we do NOT follow best practices already, and sends us on the wrong path to doing so, having to explain ourselves.

A quick run down of the article: getting requirements, D.R.Y., refactoring, test-driven development. Why on Earth assume we're new to this. Grab any amateur framework for web dev and see what it's about. Framework people's mantra is all about D.R.Y. and even taking it to inappropriate extremes.

But I do use best practices, and I believe many do. Here's the catch: there's no single set of best practices.

On the server side the task, dev tools, and target platform are quite classical, and hence the best practices are similar to classic development (and it's mostly classic development after all, parallelizable task).

On the client side we have several awfully inadequate standards, with several awfully inadequate clients (browsers) that interpret those standards more subtly or less subtly differently, and all of this runs in a sandbox, streamed through the tiny pipe of our site visitors/service users. It's a brand new challenge, with brand new bottlenecks, and has brand new best practices.

And I'd argue still many people get it right for what I see. If you believe you can do better than what we have, by all means don't just talk, but go on and do it.

Re:Misleading question (2, Informative)

herve_masson (104332) | more than 6 years ago | (#20537283)

On the server side the task, dev tools, and target platform are quite classical, and hence the best practices are similar to classic development (and it's mostly classic development after all, parallelizable task).

Web development adds specific complexity to "classical" dev platforms. You have to deal with 4 dialects at minimum: html, css, javascript, and the one that really run on the server. Worse than that: you are usually given development tools that makes possible (and encourage) to mix these languages endlessly in a single piece of code.

Web dev best practice #1 to me is: do _NOT_ mix this stuff; keep them well apart as much as you can, otherwise you endup with spaghetty-write-only-code than even you won't be able to read in a few month from its writing (I'm assuming the programmer care about that). Mixing them will also guarantee that you won't be able to reuse your code efficiently.

Re:Misleading question (1)

seebs (15766) | more than 6 years ago | (#20537721)

I have used an awful lot of web sites that very clearly do not follow even basic and reasonable engineering practices.

I know that many developers are doing their best with sucky tools, but you guys will always be outnumbered by people who aren't, same as in any other field. Most of the web developers I talk to are totally shocked at the notion that they should care about "software" engineering, when all they're doing is "page design".

In a word... (1)

dkh2 (29130) | more than 6 years ago | (#20536433)

DUH!

Better practices make for better pages that load faster, have fewer (if any) linking errors, and make minimal use of client-side work.

Only one best practice needed (1)

wrmrxxx (696969) | more than 6 years ago | (#20536535)

If/when software development becomes simple enough to reduce to a set of universally applicable simple rules, human beings probably won't be needed to do the job.

The best of best practice is to use your experience and knowledge to program in a way to suit the situation you find yourself in. Don't rely on any arbitrary list of 'best' practices to suit your particular circumstances and lead you to a good result. Including this one.

too easy (0)

theMerovingian (722983) | more than 6 years ago | (#20536681)


Web pages have become a major functional component of the daily lives of millions of people. Web developers are in a position to make that part of everyone's lives better.

I just know there's a porn joke in there somewhere...

my philosophy (1)

FudRucker (866063) | more than 6 years ago | (#20536687)

Easy on the Giggle Cream...

--Giggle Cream, it makes desserts funny...

They didnt work so well for trad projects (4, Informative)

supersnail (106701) | more than 6 years ago | (#20536785)

Traditional projects using so called "best practices" fail with atonishing regularity.

Most project failures are covered up by tha management but in environments such as UK government projects where public scrutiny makes it imposible to spin failure into success the failure rate is about 60%.

In my experience the private sector is just as bad they are just better at redfining success to be whateever crud was delivered, or, quietly cancelling projects and pretending they never happened.

I would also posit that "traditional" best practices are a big contributer to these failures.
Among the many problems:-
            1. Analysts paying lip service to user requirements but actually ramming thier own pet vision down the customers throats.
            2. Equating expensive with good. Which leads to chosing ludicrously expensive and inappropriate software where something cheap and free would have worked just as well.
            3. Dumping existing working software because it is not "re-usable" for a "re-usable" design which doesnt work.
            4. Spending eons of time perfecting design documents and diagrams as if they were the end product not just a tool for getting there.
            5. Treating all developers as equals. They arent. If you dont recognise and cherish your start programmers you will lose them.
            6. Failing to reconise the simple fact that if you dont deliver something by the second year the prohject will get canned.

 

Re:They didnt work so well for trad projects (1)

twiddlingbits (707452) | more than 6 years ago | (#20537901)

The failure rate is not what you quote. It's slghtly better. There is a firm (Standish Group)that keep statistics (CHAOS report) on the failure rates of software projects. As of 2006 only 35 completed on time and on budget and meet user requirements. However only 19% were outright failures. "Success" is different in every company so these numbers could be biased. In any other industry failing 65% of the time would be a quick way out of business.

Best Web Practices (2, Interesting)

curmudgeon99 (1040054) | more than 6 years ago | (#20536897)

Well, I have an entire website that is devoted to answering this question: Free Java Lectures [googlepages.com] is about that. Specifically, I have a lecture called "Web App Best Practices."

Requirements and Functionality First! (0)

Anonymous Coward | more than 6 years ago | (#20536985)

Well, instead of focusing on the programming side, why not focus on the requirements and usuabiliy side for once?

I don't care that you are some 'master webmaster' (ie: I can read learn PHP, Java/Javascript in 21 days..)..but give me a website that is FUNCTIONAL and usable. I don't want or need animated flashing cursors. I don't want or need 500 banners. I don't care about your java crapplet, just let me find the information I want.

Making a shopping website, just have a cart and a checkout button, nothing fancy.

Making an information website, let me search, and use boolean search.

and the list goes on and on...leave your java crapplets at home.

Last Cranky User, too. (1)

seebs (15766) | more than 6 years ago | (#20537575)

And yes, the 76 in that title is (I believe) an accurate article count. The Cranky User column has gone through something like three developerWorks "zones" and had I think six editors.

It was a lot of fun. :)

Calendar Tech (2, Insightful)

Doc Ruby (173196) | more than 6 years ago | (#20537779)

The most important part of being a Web programmer is knowing how to meet a deadline. Part of which is designing the project schedule, which means designing the product in terms of delivery dates and contingencies. And therefore almost as important is how to notice, and to communicate in advance when a delivery might be late, and by how much.

After learning how to use calendar tech and spoken/email languages for project communication, the rest of the development is relatively easy.

"Web site" is really "EAI" (2, Informative)

Nygard (3896) | more than 6 years ago | (#20538845)

In the corporate world, there hasn't been a pure "web site" project since about 1998. I said in my book, "Despite lip service, companies didn't really get off the starting line for enterprise integration until they needed to create dynamic websites. Those projects were the impetus that finally forced many companies to integrate systems that have never played well together."

The place where you need to look for actual software engineering is in the whitespace on the block diagrams. Those innocent looking little arrows that connect the boxes together are the source of most failures and inefficiencies. I've seen one little "interface" arrow implemented with 20 moving parts on half a dozen servers. (Send a message to a queue, the broker picks up the message and appends a line to a file. Once an hour, another broker picks up the file and FTPs it to the "integration server", which then slices the file into lines and uses SOAP to send messages out to a third party.) Talk about failure modes!

Civil engineers consider the loading factors, material strength, and design life of their structures. Together, these constitute the "design envelope" of the system.

Software engineers need to think the same way. How long will this system last? One year? Five years? Two months? The level of demand and demand growth over that time span matters a great deal. An architecture that works well for 10,000 page views a day will bomb badly when it's asked to serve 10,000,000. That sounds like a "duh", but it's ignored surprisingly often.

I could go on and on about engineering systems for real-world survival... but I won't do it here. (Since I already have [michaelnygard.com] .)
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>