Fragile Manifesto
Fragile ManifestoA humorous response to the AgileManifesto, written by ScottAmbler and submitted to the August edition of SoftwareDevelopmentMagazine. Sadly in many cases it is more truth than fiction.
http://www.drdobbs.com/architecture-and-design/the-fragile-manifesto/184414888
Scott concludes : As you may have gathered, this has all been an April Fools' joke. No joke. I've been involved in several projects for which my management expected me to adopt exactly the strategy exposed with exactly the same rationale. That's not fiction, that's history. Or sociology.
Another instance, reposted without permission from elsewhere in cyberspace:
The FrAgile Manifesto (Version 2.2)
We are uncovering more profitable ways of developing software by doing it fast and making lots of money.
Through this work we have come to value:
We follow these principles:
Our highest priority is to satisfy the customer through rapid and on time delivery of software that mostly works, and to provide affordable (but profitable) customer service in those cases where it doesn't work out.
We code to the requirements, because the development cycle is too short to implement any changes (unless those changes are absolutely necessary). If there are no requirements, we do the best we can.
We deliver working software frequently, every few months. Not during actual development, because customers or other departments might ask for changes that would make meeting deadlines harder if they knew what we were really developing. Developers must never communicate directly with customers. Under no circumstances should developers ever communicate directly with sales or marketing unless fighting over a parking space.
Business people and developers must work together every now and again throughout the project. But not too often, because programmers don't like meetings and it wastes time that could be spent hacking in code for the latest marketing checkbox.
Development must not provide code or executables to test until the official test cycle begins. To do so earlier might result in feedback, and we all know what that sounds like. Feedback slows development because we might develop the wrong thing, and if we had feedback we might have to start over. It's much easier to say, "It's too late in this cycle to change that."
Build projects around individuals who like to get paid. They'll do what you ask without much pushback. Give them a computer and supervise them continuously until the job gets done.
The most efficient and effective method of conveying information to and within a development team is to ask for surprise demonstrations with only a few minutes notice.
Kind of working software is the primary measure of progress. Integration should be delayed until late in the process so that nobody gets distracted by other people's work. This recognizes that all developers think that all other developer's work is crap. Avoiding technical arguments is key to the FrAgile process.
FrAgile processes promote not putting too much effort into development and even less into design. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Except when they must work overtime during integration, and then we recognize them publicly for their extra effort in keeping management looking good.
Every developer is responsible for their own work, and is not strongly encouraged to share code with one another; communication takes time, and makes meeting deadlines harder. It's cheaper to rewrite code over and over than to have valuable programming time spent talking about esoteric subjects like "architecture". Every programmer should use only the tools and class libraries that they are already familiar with, because learning stuff takes time away from meeting deadlines.
Simplicity is important, but maximizing the amount of work done is essential. Doing your own design and implementation independently of other programmers helps to ensure that your code can't get more complex than you can understand by yourself.
The best architectures, requirements, and designs emerge from self-organizing teams. But we recognize that you don't need any of these to make buckets of money. This is especially the case if individual programs don't get too large and unwieldy. The program as "object" keeps programs from getting out of hand.
Meetings of any kind involving developers are to be avoided if at all possible. Meetings take time away from producing code. Communication between programmers can only lead to coding standards and architecture, which only distract programmers from the immediate task at hand; building programs that reach the market first so they can be sold quickly and profitably. There is no shame in being second, but there is no profit either. The first vendor to lock in the customer base wins.
Keep projects small. No project should require more than two man years of development. If projects accidentally get large due to their popularity, release maintenance releases with gradual evolutionary improvements or break it up into separate individually maintainable products.
Under no circumstances ever throw away old code. We recognize the value of code that's kind of worked for many years. It's been tested by hundreds of users and it's been sort of fixed over the years. That gives it value. New code will have new bugs. Never, under any circumstances refactor code unless absolutely necessary.
Change and retraining are expensive. New development technologies should be adopted only when the old development technologies are no longer viable. Only those technologies that are widely accepted by the entire software development industry should be entertained. Choosing a new development technology is primarily a business function, not a technical one.
Avoid the implementation of standard file formats and data interchange methodologies insofar as is possible. If you create a migration path for your customers to escape, many will undoubtedly do so over time. Obscure binary file formats are our friends.
Always pick projects that are neither too vertical (such as internal enterprise applications), nor too horizontal. Find a niche market where the customers are non-technical. This is important to avoid competition from those pesky open source communists in Europe.
Branching code in your revision control system is a great way to stay out of the other programmer's way. Time wasting multi file refactoring is thus discouraged, because it would make merging branches later too difficult.
We value swamp guides over architects. Building a four lane highway across the swamp tomorrow is less important than keeping the alligators from chewing body parts off today.
Always remember that while the programmers down the street working for the struggling startup are writing elegant code, our paychecks are actually signed.
EditText of this page
(last edited October 16, 2013)
or FindPage with title or text search