eXtreme Programming is not a silver bullet

eXtreme Programming is not a silver bullet: "eXtreme Programming is not a silver bullet
brian d foy


brian d foy
RSS 1.0 feed for brian d foy. Atom feed for brian d foy.
Apr. 19, 2004 02:01 PM
Permalink

Print. Print
Email. Email weblog link
Discuss. Discuss
Trackbacks. Trackbacks
Blog this. Blog this

URL: http://www.ddj.com/articles/2004/0405/...

Matt Stephens and Doug Rosenberg (co-authors of eXtreme Programming Refactored: The Case Against XP) wrote 'The Irony of Extreme Programming' for the latest Dr. Dobbs Journal (which you can also get online with a membership).

They point out some of the things that I have thought for a while: eXtreme Programming (XP) has a lot of nice ideas, and it mitigates some problems, but it is neither a religion or a cure-all. In fact, it can create some problems of its own if not used well.

I like that they step back from the hype to look at some of the problems. I think the programming world (or maybe just the world, unqualified) tends to get too caught up in using a particular process or technique, even if common sense says something else. I have often told those close to me that if they cannot criticize their favorite thing, they do not know it well enough.

They quote an email one of their readers sent them:

The pair programming is mind numbing. With this XP stuff, software development is no longer a professional occupation, it's just another type of assembly line work.

Different people have different ideas about that, and as I write this from Detroit, home of the Henry Ford Museum, I wonder if those great innovations I learned in elementary school, like division of labor and the assembly, caused the same reaction. I would certainly expect that demoting a master craftsman to the assembly line would cause some problems, so why do some shops insist on doing that to senior developers just so they can say they practice XP?

brian d foy is a Perl trainer for Stonehenge Consulting Services and is the p"

Cryptographers to Hollywood: prepare to fail on DRM [printer-friendly] | The Register

Cryptographers to Hollywood: prepare to fail on DRM [printer-friendly] | The Register: "Cryptographers to Hollywood: prepare to fail on DRM
By John Leyden (john.leyden at theregister.co.uk)
Published Thursday 17th February 2005 19:37 GMT
RSA 2005 Movie industry representatives at RSA 2005 in San Francisco today called on the IT industry in thwarting illegal file sharing before the problem threatened its revenues. But they were told that they must recognise the limitations of digital rights management their fight against digital piracy.
Speaking on the RSA conference panel Hollywood's Last Chance - Getting it Right on Digital Piracy, Carter Laren, security architect at Cryptographic Research, noted that cryptography is 'good at some problems, such as transmitting data so it can't be eavesdropped or even authentication, but it can't solve the content protection problem. If people have legitimate access to content, then you can't stop them misusing it.
'Anyone designing content protection should design for failure and if it fails update it,' he added.
John Worrall, marketing VP at RSA Security, agreed that content protection systems should be easy to upgrade. The entertainment industry must also learn from its previous mistakes in pushing the weak CSS copy-protection system for DVDs: 'If content providers open up standards to good cryptographic review they will get a better system,' he said, to applause from the RSA 2005 audience.
The entertainment industry also needs to be responsive to changing market conditions and consumer preferences, according to Worrall: 'Don't lock down a set of content rules that look draconian five years from now. Be flexible enough to incorporate change in rules. If rules are too restrictive people will go to other channels, including pirated material."

Embedded.com - Software synthesis for embedded systems

Embedded.com - Software synthesis for embedded systems: "Software synthesis for embedded systems
By Bob Zeidman
Embedded Systems Programming
(01/20/05, 14:32:00 H EST)


Synthetic operating systems might mean never having to port software again. Software can be automatically generated-synthesized-to meet the demands of a changing system.

For decades hardware design began with a schematic-a graphical representation of the hardware that could be turned into components and wires, a printed circuit-board layout, or a semiconductor chip. At first the process was done manually with hand-drawn schematics that were translated to layouts by highly trained draftsmen. The process was later automated with schematic-capture tools, automatic netlist generation, and physical-layout programs, though the concepts remained the same. Eventually, chip designs grew very large and a new design method was needed. Thus was hardware synthesis born.

Hardware-description languages (HDLs) similar to programming languages were developed and now all chip designs begin as lines of code. The code is written at a high level that hides much of the complexity from the designer, and then is synthesized into a low-level description for layout and analysis. I'm proposing that the time is right for a similar evolution in embedded systems software design.

Synthesis is the process of taking a high-level description and turning it into a lower-level description that, in the case of software, can be compiled directly. By working at a higher level, the user is kept uninvolved with implementation details. Synthesis employs automatic code generation (ACG) but there's more to it than that. Some popular and useful code-generation tools already exist. Microsoft Visual Basic and HTML-layout tools like Macromedia's Dreamweaver allow users to create graphics and buttons with little or no knowledge of the underlying code. These kinds of ACG tools are indispensable for creating a user interfa"

Path and Classpath in Java SDK and JRE