Software Development: Process & Features

• ongoing conversation: with stakeholders; always in the loop, we can twiddle the bits as we go along, reorient, reprioritize, collect and act on feedback
• iterative development: start with blank slate, add feature, tweak, software Always Works and Does Something Useful, and we grow it organically
• use Software-as-a-Service: (examples: Gmail, Google Docs, Basecamp; benefits: pay-as-you-go and externally hosted, with no upfront costs, very fast signup, no capital investment costs, much reduced internal IT staffing requirements, and easy, usually-free upgrades)
• use pre-existing components: so don't reinvent the wheel (OS, database, editors, tools, servers, browsers, multimedia apps, etc.)
• use Open Source software: (examples: Linux, Apache, Django; benefits: because you have the source code you can study/fix/customize it directly, not held hostage to a vendor, no proprietary code lock-in making it difficult/costly to port away, widespread community support, and almost always free under some license terms)
• utility computing: (examples: Amazon Web Services, Google App Engine; benefits: metered billing similar to water or electricity which charges you only for the resources used (cpu, memory, disk, network), sometimes cheaper at small traffic loads (GAE yes, AWS maybe no), but much easier and more affordable to scale up to handle higher visitor traffic (from incremental growth) especially for spikes (such as from splash-like publicity events) -- you want your site and systems to be available and responsive when they're most needed and can make the biggest impression, positive or negative, on a large amount of people)
• use concise, high-level, rapid-development-friendly programming languages: like Python or Ruby, rather than verbose compiled languages like Java, or low-level unfriendly languages like C; results in less dev time to add features or fix bugs, faster time-to-market; Python will be the default language considered for any custom programming needed, but the actual language(s) used may vary by project, whatever make the most sense for a project: we're idealistic but pragmatic, not dogmatic
• risk & urgency ordered development : could also be called RP1 for "riskiest pieces 1st" or schedule demand triage; the strategy here is to identify all the elements of the system you want to build and then categorize each element into a 2D grid of buckets, where one dimension has "must now | nice soon | maybe someday" as column headers, and the other dimension has "straightforward | risky or questionable" as row headers. (TODO: add illustration.) For example, let's say you're going to start a robot company. For the first dimension you might put "build robots" in the "must" category, then put "client-specific programming" in the "nice soon" category, and then "leather couches in every office" in the "maybe someday" category. Because clearly you must build robots (or, well, acquire them from somebody else) in order to have a robot company. Now analyze along the second dimension. An element like "write control software" would go in the "straightforward" row, whereas "build robots for the Pentagon" would go in the "risky or questionable" row. Since if you have decent programmers you can clearly write control software. But will it be too much of a pain in the ass to make a product for the Pentagon? Would the paperwork and bureaucracy and legal/financial requirements be too much for your tiny startup to get off the ground? If so perhaps instead of making robots for the Pentagon you should instead make robots for the home, or for shipping warehouses, where an individual consumer or ambitious business only has to make the decision to buy and can execute on that decision quickly. An element like "have a website" is both straightforward/nobrainer, but also not in the "must now" column --- it would be in the "nice soon/eventually" column. So don't worry about making a public website first thing, just get around to it eventually after you've taken steps to test and derisk all the business elements that lie at the intersection of the "must now" column and the "questionable/risky" row. (Caveat: may be good idea to make a splash/teaser website, something simple, even before you've derisked everything upfront. But don't spend time adding "Facebook integration" for your robot company until you're pretty damn sure you can definitely make and sell robots.)
• sprints: bundling up dev work into batches performed in sprints, to be efficient time-wise and dollar-wise (developers should spend as much time in "The Zone" as possible, with minimized interruption, in order to maximize productivity and minimize bugs; The Zone is software development lingo for an intellectual state where everything the developer needs to do is fresh in their short-term memory, including a clear understanding of the current codebase, what tasks need to be done, and what the dependencies and possible interactions are between the code they are dealing with, and other code above or below it, or downstream from it; sometimes also described as a 'code trance' or thinking like the machine)
• automation: aggressive automation of otherwise manual tasks (Python & shell scripts); examples: scripts, tools, templates, builds, tests, deploys, monitoring production & taking corrective action
• version control: git (by default, though I can use a different system instead, or in addition, as needed)
• frequent periodic automatic backups: cron and Time Machine
• fast, secure online delivery: DropBox (by default, though we can use another means if desired)

home