My Software Craftsmanship
book is now available in bookstores everywhere, as is Questioning
Feb 2003 What to do when the Estimate is
Wrong a lighthearted look at how projects get estimated, and how project
InformIT has post a series of my articles
throughout the start of 2002.
Death March Projects explains why death march projects are not inevitable.
the Fallacy of Good Enough Software asks every manager, team leader, and
developer to fight back against the idea that bugs are inevitable.
The Waterfall Of all the ways of approaching the software development
lifecycle, the waterfall is probably the worst. So why does it continue to
dominate our thinking? Simple: We have failed to let everyone know how software
development really works.
- How not to get burned by your next Java project. This article follows up on "How to Crash and Burn Your Java Project" with survival strategies for developers so that the impact of poor decision-making is minimized.
How To Be A Developer Does the popular "sheep dip" model of short training
courses actually help people become better developers? Is teaching as a performance
art really the way to go? The time has come to shift our attention away from
teaching and think instead about what it takes for people to really learn
how to be great developers.
of Software Craftsmanship By replacing the traditional software engineering
metaphor with software craftsmanship, we open a whole new realm of possibilities
for the software development community.
to be Agile Agile is in. Many processes and projects are jumping on the
bandwagon and claiming to be Agile, so what are the telltale signs that what
you have is a traditional process just pretending to be Agile?
- What are XP projects scared of? A chapter extract from Questioning XP
a Software Developer series on InformIT. In the age of objects and the Internet,these articles show how Ruby
fits a whole new generation of developers.
1 Ruby for the Nuby When first learning how to write software, immediacy
wins every time. Beginners are helped by the immediate feedback that comes
from interpreted languages. Many developers first learned to program using
interpreted BASIC on a home computer. In the age of objects and the Internet,
Ruby can fulfill the same role for a whole new generation of developers.
2: Test Driven Development with Ruby Developers can become more productive
and spend a lot less time debugging code by creating Extreme Programming
style unit tests before the rest of the code is written. Every "Ruby nuby"
should learn about test-driven development and create unit tests.
Version Control for Fun and Profit Although version control is an
old technology, few developers take the time to think about how it can
help them become more effective. This article looks at how frequent versioning
can take some of the stress out of software development.
4: Understanding Use Cases and Requirements Where do requirements
come from? How can use cases help to record requirements? What does a
good use case look like? What do I do with a use case once I have it?
Creating Acceptance Tests from Use Cases Use cases are a fantastic
aid to quality assurance activities because they provide the information
we need to design acceptance test cases.
6: Design and Programming or Why Programming is Hard The step between
having a design idea and the "simple matter" of programming that idea
is a massive one. Understanding why programming is not easy is a first
step toward mastering the craft of programming.
7: Ruby for the Internet Nuby It's easy to write simple scripts for
sending emails but hard to make sure that your application deals with
all the weird and wonderful things that can go wrong.
By Design Part 1: Avoiding Rotten Code We all have to face the fact that
some software stinks; it doesn't work right or it just plain feels wrong.
Fixing these problems is simple, but may not be easy. We have to understand
the nature of software development and make sure that we allow ourselves enough
time to do a good job.
by Design part 2: Healing Legacy Code Many organizations complain that
their legacy systems are unmaintainable, but guess what? The organization
let the code get that way by not paying attention to the design of the teams
that created and maintained the code. Refactoring the code may provide a stopgap
measure, but refactoring the organization is a better solution.
Praise of C and C++ See why many developers prefer C and C++ over other
rapid development tools. C and C++ enable developers to create long-lived
predictable applications and to interface to legacy code on practically any
Incremental Development, a followup
to the earlier Incremental
Requirements article, looks at what it means to do Incremental Development
from the point of view of the development team and the users of applications.
How to Crash and Burn your Java project
Since many Java projects seem destined to fail I though that it would be useful
to provide some advice on how to speed up the process. This article is a
parody. Any resemblance to your project is purely coincidental and should not
be taken as any indication that your project will actually succeed in it's goals.Also available on the InformIT
Website: How to Crash and Burn your Java project (login required, registration
Applying the Lessons of eXtreme Programming
(36K pdf) Although eXtreme Programming has been explained by Kent Beck,
there are many benefits to adopting eXtreme Programming (XP) practices in other
development processes. The benefits of adopting the complete XP approach are
outside of the scope of this paper, what is discussed here are the lessons that
XP offers to other development processes. This paper initially discusses the
benefits available from adopting XP style unit testing on a project, and then
moves on to identify useful lessons that can be learned from other XP practices.
The paper concludes by asking questions about the nature of process improvement
in software development and how we can make our software serve society. Please
note that this paper is © 2000 IEEE. Personal use of this material is permitted.
However, permission to reprint/republish this material for advertising or promotional
purposes or for creating new collective works for resale or redistribution to
servers or lists, or to reuse any copyrighted component of this work in other
works must be obtained from the IEEE.
Is XP for Everyone? Although eXtreme Programming
is very visible right now and is starting to dominate the conversation about
Lightweight or Minimal Methodologies, there are many alternatives available.
Read on to ponder the question "Is XP right for your team or not?"
Test Cases from Use Cases Creating Test
Cases from Use Cases turns out to be very easy when using Alistair Cockburn's
format for Use Cases, testers will thank you for using use cases.
Using Use Cases for Requirements Capture Use
Cases have proved to be an effective mechanism for the capture of requirements.
This document uses Alistair Cockburn's format for Use Cases and adds in ideas
about how to create and review Use Cases.
Requirements (at the Extreme Programming
website). This paper talks about the distinction between of Capturing
Requirements for Prioritization and Capturing Requirements for
Creativity in Software Development
Creating Software is one of the most creative activities that humans undertake.
The main limitation in software is the Human Imagination, and the limits on
that are all self imposed. Through the Software Engineering model we see a linear,
sequential model of Software Development, something that drastically reduces
our ability to create really great software.
Uncertainty in Software Development Uncertainty
is one of the few certainties about software development. As humans we are
not very good at creating precise estimates, but we all crave precision
when we recieve estimates from others. This paper explores these ideas. The
Illusions covers similar ground in a lot more detail.
The Myth of Change Control The Software Engineering
model of Software development has a major flaw. There is an association with
a linear, sequential process, we even have a neat name for this linear, sequential
process, the "Waterfall" life cycle, where everything flows neatly
from one stage or phase to another. Although this "waterfall" process
of software development has supposedly been proven to be invalid, most software
developers still talk as if it is alive and well.
OOPSLA 99 Design for maintenance workshop
details are available. As are the TOOLS
USA 2000 Workshop on Education and Training (WET) details.