Software development concepts

From Consumerium development wiki R&D Wiki
Jump to: navigation, search

14 day sprint

The 14 day sprint is half the length of the 30 day sprint and one-sixth the length of the 90 day sprint. It is the shortest development cycle that anyone ever really talks about presently. It might be possible to cut it to a 7 day sprint with a 24x7 global development process, but no one has really done this, and it would require much better methods of making programmers from many places all over the world co-operate. Starting point for this is a really great glossary that is so exact that no one, regardless of culture, could get confused by it.

Main features differing in the 14 day sprint are, obviously:

  • its length - in half the time, less than half the work can get done, since the overhead is the same, and no, lacking sleep won't solve the problem
  • the daily scrum meeting is probably a bit more exact and uses the glossary terms very carefully to be sure everyone's on the same page - there is less recovery time in case of big mistakes
  • off-hours contact between team members is probably more common, e.g. at Microsoft, any member of the team can contact anyone else at any time, even at home at 3AM
  • more need for civility, less for team members to like each other long term
  • a stricter control of meeting styles to ensure sidetracks don't happen
  • more tolerance for use of consultants, ringers, contractors, cheap outsourced coders, and others as long as they are ready to fit the schedule

The 14-day sprint is common for small followup projects, exploiting some opportunity opened by a previous 30 day sprint or 90 day sprint.

It is most usually seen in advertising, campaign work and the media, where most things are deadline-driven. It is also common for a rigged demo.


30 day sprint

A 30 day sprint is a short burst of work lasting at most a month (see 14 day sprint for a shorter cycle appropriate to media-driven work like advertising and elections and other campaigns). An executable and other deliverables are built by a "cross functional team consisting of no more than 9 members" working towards a very specific goal. According to the most active promoters of the 30-day schedule, basic to the scrum methods, the rules are:

  • "An executable demonstrating the goal will be completed by the team during the sprint."
  • "The sprint team has final say in estimating and determining what they can accomplish during the sprint."

14 day sprint if there is a chance of surprise "ideas" or "requirements" emerging between the start and the end.

  • "If external forces determine that the sprint is working on the wrong thing, a sprint can be halted and restarted with new backlog and purpose." This may be a good argument for starting multiple sprints in parallel, especially if one is using cheap outsourced coder talent.

90 day sprint

The 90 day sprint is the longest development cycle usually recommended for complex systems including software. It is appropriate for the core technology of a startup company, proof of concept in a corporate joint venture, or very complex integration projects (like a Consumerium pilot).

Once the core technology is integrated, followups should be 30 day sprints and minor features added for tactical purposes should be 14 day sprints - but a major change to the healthy buying infrastructure should be its own 90 day sprint separate from the specific Consumerium Services.


cheap outsourced coder

Many people think that the cheap outsourced coder living in Russia, India, Pakistan, Kazakhstan, Malaysia, or other places with many well educated programmers are a threat to their jobs (often charging as little as US$10/day).

However, there is plenty of reason to work with them on Consumerium Services when the Consumerium Governance Organization deems that it is not a good idea to wait around for free software or open source software or buy some commercial product:

  • They do not invent their own bogus requirements or strange user interfaces, e.g. tikiwiki.
  • They do not have 100 other priorities before they get around to yours, e.g. mediawiki.
  • They can learn Python if you pay them to - seems many FS geeks can't!
  • They are not afraid of ugly grunt work like writing a nasty device driver.
  • They could be chosen from people who support fair trade or ecology causes already, and so would have strong ideology reasons to do a good job. However, free software geeks very often have strong ideology reasons to make it hard to work with non-free software, which is not that important to Consumerium, which will no doubt have to work with lots of strange stuff to make it work.
  • They are so cheap, donations from rich developed-world programmers doing a few hours a week of work could pay for a week of their time, and that would make the rich developed-world programmers "managers" at least for this one project. Probably it helps everyone's career.
  • When it is hard to explain a concept to them, they can be sent to read about it in the Wikipedia, and when stupid people there censor them and say "you are trolls", that will be a couple more smart programmers angry at Wikipedia and ready to help destroy it with massive denial of service attack.