The term “deadline” is commonly heard in software development. It generally refers to a date by which a project must be completed. In the software development team at Roompact, however, this term is never used, and the notion of a must-be-completed-by-date is only ever raised in special circumstances. Why? Deadlines exist in a space that is far removed from software development, and the former is mostly incompatible with the latter. While we do commit to releasing timely features for our partners, we also commit to excellence.
Deadlines are conceived in a domain of transience, where schedules and calendars are strictly adhered to. Where it somehow makes sense for a meeting to last exactly one hour. Where a presentation is shown once and then fades into the memories of its viewers. Where, more often than not, the output of whatever is mandated by a particular date and time is transitory. In this space, a mistake is experienced once and forgotten shortly thereafter. A hastily designed piece of content never faces heavy scrutiny, as its first examination is often its last. Material is viewed or read but seldom used in a more tangible manner.
Software exists in a domain of permanence. Its presence comes with an expectation of reliability. Its purpose is to be used directly, often continually. A mistake in this domain will be experienced repeatedly, and manifest itself as far more than a memory. An error can result in wasted time, lost information, frustration, and even tears. Few have ever cried because a Powerpoint presentation contained a mistake—other than the presenters, perhaps. Many have cried because their work failed to save correctly.
In the domain of transient projects, deadlines can play a positive role. They can guide an individual or a team to get a piece of work done in a predictable amount of time. They create an impetus to push a project towards completion. The rate at which work is being done can be increased at a degree that is inversely proportional to the amount of time remaining. Then, once the deadline arrives, the work can be released as is (bar a few last minute touches and polishing). Whether it be a piece of marketing material, a sales presentation, or a college paper, this technique usually produces satisfactory results.
However, the aforementioned approach only works when either the life expectancy of the output is short or it will not be heavily relied upon. Both permanency and reliability are expectations that are rigorously applied to most software. As a result, imposing strict deadlines in software development readily becomes counterproductive. A hastily designed piece of software needs to be revised because it is missing key features. Users get angry when they experience bugs. A lot of time and money has to be spent to get software engineers fixing issues that were born out of moving too quickly, or cutting too many corners. Even more expensive is regaining the trust of users who have had unpleasant experiences with the software in question.
At Roompact, the software development team uses a number of methods to ensure its efficacy. Projects are planned extensively at their outset, so that seldom, if ever, are there surprises as to their overall length and complexity. Communication between engineers is frequent and deliberate, so that time is not wasted on unnecessary or redundant work. Feature scope is often adjusted, both to address feedback that is received over the course of development and to help the team arrive at a point where an initial release is feasible. Expectations are set and then reset. It is through these tenets of planning, communication, and flexibility that productivity remains consistent and the need for deadlines is eliminated.
Software development is a process of discovery. It involves identifying problems and inventing their solutions. It is also a process of creation; the formation of something new. The act of building software requires an iterative application of this cycle of problem identification and solution invention. The problem is that nobody really knows how long building a solution will take. This is why setting deadlines, although enticing, is usually at odds with the goal of building useful and dependable software. Deadlines in software do not produce results faster or more predictably—they just produce inferior results. At Roompact, we strive for excellence.