“Oh, that’s easy. I can do it in a weekend”

In this blog post, The One in Which I Call Out Hacker News, Benjamin Pollack explains the reasoning behind a developer’s thinking that implementing something is simple, in this case, the claim that a developer could write the functionality behind Stack Overflow in a weekend.

When you put a developer in front of StackOverflow, they don’t really see StackOverflow. What they actually see is this:

create table QUESTION (ID identity primary key,
TITLE varchar(255),
BODY text,
UPVOTES integer not null default 0,
DOWNVOTES integer not null default 0,
USER integer references USER(ID));
create table RESPONSE (ID identity primary key,
BODY text,
UPVOTES integer not null default 0,
DOWNVOTES integer not null default 0,
QUESTION integer references QUESTION(ID))

If you then tell a developer to replicate StackOverflow, what goes into his head are the above two SQL tables and enough HTML to display them without formatting, and that really is completely doable in a weekend.

Benjamin acknowledges that that is indeed the core functionality behind the site, but then he lists all the other things that comprise the site–administration functionality, user functionality, look and feel, usability, etc. Furthermore, he points out what makes Stack Overflow successful is not really the core functionality, but all these other things. And implementing them successfully would take a lot of time–orders of magnitude longer than a weekend.
I would argue that it is often this thinking that often leads to software delays and poor quality. All the details that have to be covered are not taken into account when planning. The good news is that agile’s focus on breaking work into small units can help to counter this type of thinking. In the process of delineating all the tasks associated with a user story, the team should identify all of the details that are required for completion of the user story in the application.

QA’s dirty little secret

In my experience, one valuable skill that I’ve brought to the software development process is one that nobody wants to talk about: the willingness and ability to do tedious tasks that nobody else wants to do. Manual testing is the first such task that comes to people’s minds, but another example is going through the defect system on a regular basis to ensure that all defects have the proper data.
The good news is that agile has lowered the value of this skill. For one, making sure that processes, such as defect tracking, are followed is a team responsibility. Therefore, team members are more likely to do the right thing without being audited and the pain of bookkeeping lapses is felt more by the entire team.
More importantly, however, with agile there are simply fewer repetitive, tedious tasks. There is no process-for-process’ sake, so processes such as defect tracking workflows are reduced to the absolute minimum to make them work, and if they aren’t serving their intended purpose, they are adjusted based on feedback from the sprint retrospective. And since the pain of repetitive tasks are felt more by the whole team, there’s a greater emphasis on removing or automating as many such tasks as possible.