Editing Software development concepts

==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 [[cheap outsourced coder|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 style]]s to ensure sidetracks don't happen
*more tolerance for use of consultants, ringers, contractors, [[cheap outsourced coder]]s, 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 [[campaign]]s'').  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."
*"Once the sprint is underway, new backlog cannot be added to the sprint except that, if the scrum master determines that a new backlog item will enhance the viability of the product, is in alignment with the sprint, builds on the sprint�s executable, and can be completed within the sprint�s time frame, the backlog item can be added. Examples are building a demonstration of the executable for a specific purpose, such as a trade show or prospect."  ''It may be useful to consider a shorter [[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 sprint]]s and minor features added for tactical purposes should be [[14 day sprint]]s - 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]].