Slashdot Mirror
Best Programming Practices For Web Developers
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?"
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.
I've fallen off your lawn, and I can't get up.
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.
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.
.: Max Romantschuk
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
A polar bear is a cartesian bear after a coordinate transform.
"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.
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.
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) 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.
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.
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...You can attach boosters to anything. It just costs more. -
Anonymous Coward on Sunday November 07, @12:26PM
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.
Old COBOL programmers never die. They just code in C.