Development Process
Our team uses a streamlined Web development process and methodology for all the sites we create. The intention is not to add overhead to the project; on the contrary, we're looking to provide just enough structure to provide a predictable outcome on a predictable timeline.
The process has three phases: Discovery, Implementation, and Maintenance.
Discovery Phase
Discovery is the process whereby we determine, in detail, what a customer is asking us to build. In some organizations, this is known as "requirements-gathering". It always starts with a conversation with the customer to determine their business requirements, and it and concludes with a set of deliverables that specify what's going to be built.
Discovery phase deliverables typically include:
- A product requirements document (PRD), stating in detail the various features of the site that are to be built;
- One or more wireframes that provide a quick, rough guide to how the site's user interface elements will be arranged on a page;
- One or more mockups that provide a more fleshed-out user experience design, showing in graphical format what the finished site can look like;
- If necessary, one or more prototype pages to demonstrate new or unusual user-interface paradigms;
- A domain model, a diagram that specifies the various high-level concepts in the application and how they operate with each other;
- A data design, to determine how information will be stored and retrieved;
- A system architecture, which specifies how the various aspects of the system will work together.
The duration of the discovery phase depends upon the complexity of the customer's requirements and how much work the customer has already done to enumerate their requirements.
Another deliverable that is typically provided at the conclusion of the Discovery phase is a time estimate for implementation. Estimates are necessarily the last deliverable of the Discovery phase, because nobody can have sufficient knowledge to do an estimate until the discovery phase is complete.
Some Discovery phase tasks aren't always necessary. For example, if we're building a site on an established platform such as Wordpress, we still need to gather requirements and do user-interface mockups, but we might not need to do a data design or system architecture (since those elements are provided by the platform).
Implementation Phase
In the Implementation phase, we create the site based on the specifications we developed during the Discovery phase. Implementation mostly involves writing code (including HTML, CSS, Javascript, server-side code in a language such as PHP, and data queries written in SQL), but it can also involve other activities such as testing, setting up software and servers, and rendering images.
During implementation, we provide an online issue tracker, source code repository, and a staging server.
The issue tracker is where we maintain the project's master "to-do" list, as well as bugs and other activities that need to be completed. Because we find that task information in email or documents tends to get misplaced or miscommunicated, we try to ensure that tasks and bugs find their way into the issue tracker. This has the positive side-effect of providing an easily accessible written record of the decisions we've made as the project progresses. Giving customers and other stakeholders access to our issue tracker is important because it gives everyone insight into what we're working on, what our priorities are and how much progress has been made.
Tasks in the issue tracker are commonly grouped into milestones (often associated with a specific deadline). As we begin implementation, we typically implement a feature freeze, which gives us the ability to meet a deadline and provides the customer some measure of cost control over the project.
The source code repository is where the code for the project lives. The most important function of a source code repository is to manage conflicts between different developers' changes, enabling us to manage conflicting changes to code intelligently and making it easy to go back to a working version of the code if something we did doesn't work for some reason.
The staging sever is where everyone working on the project can review and test the site prior to launch. The idea here is to prevent disruption to the production Web server as we add features and change things around. We try our best to keep the site under development in a usable state on the staging server so customers and team members can review our progress at any time. From time to time we'll do a staging push, in which we move code from our development machines to the staging server so everybody can review recent changes to the software.
Maintenance Phase
In the Maintenance phase, we deploy the Web site to the production server and plan for the next iteration. This can mean getting started on the next implementation milestone if one has been planned, or to kick off a new Discovery phase to plan significant new features. It is often possible to do Discovery-phase product planning prior to the conclusion of the current implementation milestone.
We provide hosting for our customers' Web sites based on a server infrastructure that enables us to easily grow or shrink the size of the site according to customers' needs. For a single-server configuration, upsizing a server can typically be done with about ten minutes of down time; we can plan the down time for a period when traffic to the site is low. For a multi-server configuration, we can typically resize each server individually with little or no down time. We also provide regular offsite backups and uptime monitoring as part of our hosting services.
Redmond Channel Partner on HP's Acquisition of Palm
Platform Associates CEO Jeffrey McManus is quoted in a piece in Redmond Channel Partner magazine on HP's impending acquisition of Palm.
There's A New Mayor In Town
Governing magazine did an interview with the BART web team on their integration with mobile social game Foursquare. In the interview the team describes the rationale for using Foursquare and how BART's embrace of open data platforms and social communications has worked for the transit district.
Fake Steve Jobs: "Developers only now realizing that Android is not a platform"
According to Gadget Lab, app writers have somehow just realized that the reason open source fails in customer-facing use cases (as opposed to back on the server in a locked room) is that it splits like a bead of mercury into a zillion different forms, and nobody can write apps that work across the platform [...]
Amazon EC2 and Windows Azure
Platform Associates CEO Jeffrey McManus is quoted in a story in today's Redmond Developer News. The piece discusses Microsoft's Windows Azure cloud offering in light of new product releases and aggressive pricing by competitors such as Amazon EC2.
