Via Marty Andrews, An Introduction to Agile Methods (PDF)
[Traditional methodologies] have a few things in common – they assume that software development is analogous to a defined industrial process; they are based on physical engineering processes; they are predictive; and they assume that people can be treated as abstract resources.
Well worth a read – agile methodologies are particularily relevant to PHP.
Which reminds me to blog some more about meeting Jules, who mentioned being struck by the meaning of Lastcraft…
A craft is defined as…
“Art or skill; dexterity in particular manual employment; hence, the occupation or employment itself; manual art; a trade.”
If you lose a screw or clasp from a hand made jewellery box it is hopeless to try to find a replacement. Nothing else is quite the same and the mechanism will fail to work. It may even cause more damage when applied. You need to find the original maker or someone of the same skill to make you another. Sound like software? Yet mechanical parts today are interchangeable.
Writing software has resisted mass production. As soon as a part of it becomes routine it can be automated. Once it is you don’t need a programmer any more. Routine programming jobs no longer exist. All that is left is the unsolved problems that require a higher level of skill in constructing their solutions.
This dependency on the ability of the artisan, combined with nothing quite fitting together properly, is what gives software the pre-industrial feel.
…it’s the last craft.
Related posts:
- Brainstorming: The Cubing and Webbing Methods In the second post of a three-part series, Alyssa explains...
- An Introduction to JavaScript for Acrobat I’m always interested to see how JavaScript works on non-browser...
About 100 years ago if you wanted to buy a car you would have to commission a person to build it for you. The bolts and nuts were non-standard.
Then Henry Ford introduced standards and the assembly line.
Today. How many engineers does GM empoy?
July 16th, 2004 at 9:13 am
I think that one should aim to develop a framework to allow for mass production, but the programmers job is still important and relevant as they can continuously work to refine the process and the code used. In short, projects should consist of custom made classes and libraries that can be tied together by someone with minimum programming knowledge, while the programmer can ensure top quality and constant refinement and evolution of those classes.
Just a thought.
July 16th, 2004 at 9:25 am
It’s funny – in a way languages like Perl, Python and PHP are a step away from mass produced development.
Think I large part of Java’s success has been the evolution of standards aimed at specifying the “nuts and bolts” and the appeal that has for project managers.
Meanwhile an applications written in PHP usually reinvent all sorts of wheels (e.g templates) but PHP is also a big success thanks to it’s “immediacy”.
July 16th, 2004 at 10:29 am
HarryF makes a good point about immediacy.
To draw on the making cars analogy… in any craft, back when things were mostly hand made, it was easy to get started. When cars were mostly hand made, it was easy to get started learning about making them. Even when the components became mass produced but the things were still hand assembled, it was easy enough to learn about. Learning to fix the cars was also easy to start. (Of course, mastering making cars took a lot longer… but the beginning was simple).
Now, cars are very mass-produced. To fix them, you need some kind of computer that talks to the engine and finds out what’s wrong. There’s complicated self-check systems everywhere… and under the bonnet can be mysterious in the extreme.
The analogy is this: PHP is like how cars used to be made. Lots of people can pick up a script and hack it about a bit. Doing so might inspire them to learn more.
Something like C++ with Microsoft Foundation Classes is like cars now. It takes a lot to get started learning what’s going on. Someone who’s mildly interested can’t really just jump in, have a play, and then get some sort of reward for their efforts. There’s so much going on that it takes a long time to learn it all.
I think PHP should still fill the niche of the hand-assembled car. I’m learning Java now to take my software development knowledge further… but if it hadn’t been for PHP I probably would never have got started. (Memories of my aborted attempt at learning C spring to mind).
July 17th, 2004 at 6:07 pm
There I have to take exception. Cars are used to frequently for analogy in software development, like every classic OO text that begins “Imagine a car…”, which for PHP developers is very confusing – when was the last time you wrote something representing a car in PHP? Using forms, for example, makes a much better point of reference for OO.
More specifically, think using cars as a precedent for software blinds us to alot of key issues. Most importantly, as the above PDF points out very nicely, for customers the very notion of software implies infinite capacity for customization and tailoring to exact (and frequently changing) requirements.
I have a fundamental belief (based on hunch rather than evidence) that the majority of todays software development, where there’s a one to one relationship between developer and customer, cannot be mass produced.
Development environments that impose strict rules on the developer (e.g. everything must be an object) and frameworks that impose rigid structures will always “fail”, IMO, under a demand for truly software. By “fail” I mean significant development effort will be expended to bend the imposed rules to meet a given customers requirements.
Where I “see the future” (if that’s possible) is with agile languages like PHP that provide the shortest path to expressing human ideas in code, rather than dealing with issues which a primarily platform / system related (e.g. memory management and by extension primitive data typing). Todays generation of agile languages could do more to make life easier but compared to, say, C it’s a vast improvement. Sadly none of the big software houses are committed to agile languages right now.
July 18th, 2004 at 8:49 am
darvarouleto
November 8th, 2008 at 10:42 am