Many smaller and non-technical businesses are not familiar with web development process and thus may not fully appreciate the need for it. Many times, the development team is pushed to override process either because it appears wasteful, interferes with a more organic process, or because there are looming deadlines that conflict. While this may facilitate short-term goals, it is rarely beneficial in the long term. The goal of this article is to describe the challenges that face the development team without process, the longer-term consequences, and ultimately to provide a road map to a lightweight process that may work well for a small business or non-technical business.
Organization – Without process in place, most small and non-technical businesses will act as a pitcher and expect the developer to be the catcher. Meaning ideas are thrown at the developer for implementation, and the developer must pick up these changes and respond to them. Sometimes these emails are coming from different people within the organization, some of whom aren’t even authorized to request changes. Often, most one of these requests are the top priority and all need to be completed today, regardless of what’s involved to complete the task. This leaves the development team with no ability to manage their schedule, no opportunity to set expectations for how long a request should take, and no ability to truly manage priority for the tasks. You can see how this can get complicated really fast. It becomes very easy in an environment like this to miss incoming tasks, not prioritize effectively, and ultimately not manage productive time well.
Team Impact – Aside from the organizational impacts mentioned above, consider what happens to the focus and emotional state of a developer responding to this environment. They begin to get confused, stressed, and may begin to feel pressure to get things done. In a more prideful developer, this will lead to ‘grumpy’ interactions with others on the team, as they are going into lockdown mode, trying to get things done the ‘right way’, and ‘despite the team’. On the other hand are developers who respond to the pressures to get everything done quickly, start to stress out, speed up and take short cuts, which increase the risks of making mistakes and risk of secondary ‘regression’ bugs popping up in existing code. Ultimately management and/or the team around the developer will get frustrated regardless which of these two paths is chosen. Who is happy here?
Quality Impact – At a very fundamental level, developers are creating a system. They take the business rules defined by the business, translate these into logical statements and create order out of the collection of requirements. That is how things *should* be working anyway. Consider what happens when a series of unrelated business requirements becomes a barrage of piecemeal emails, all of which have urgency attached to them. The path of least resistance for the developer at that point is simply to comply with each request as asked but unfortunately that means any attention to maintaining architecture and system design is lost. Rather than writing (and documenting) meaningful modules that interoperate with the system in a reasonable and predictable way, the features are just being added in the quickest way possible and with no documentation to explain the ad hoc logic that is no longer consistent with the underlying system to which it was applied.
The result is code that is increasingly difficult to maintain, understand, and develop against without risk of causing new errors. So even if the developer succeeds in responding to the ad hoc requests, in the long term he will be blamed either when a new developer one day arrives and talks about how bad the system is coded, or when the team and management grow tired of all of the bugs later in the incoherent system that walked away from or didn’t implement a reasonable system design. Its a slippery slope that only the more ‘grumpy’ developers can avoid but then these developers are scorned in the short-term for being difficult to work with, and unresponsive to the business priorities. Who wins in this environment?
The only reasonable solution to this problem, is to take a rational approach to development – process! For businesses who are resistant to process, iterative methodology provides a much more lightweight approach and allow developers to be more responsive and agile (pun intended) to the business than more traditional waterfall methodology. Using an iterative method, the team will begin to work within a structured iterative schedule, typically 1-4 weeks in length. For example, assuming the iteration is one week in length, a design session happens on Monday, development occurs Tuesday through Thursday, user testing occurs on Friday, and development occurs Friday evening, during low traffic hours; the same process is repeated every week.
During the prior week, the business stakeholders have been compiling a prioritized wish list of features and bug fixes they want to complete the following week. Then, at following Monday’s design session, the team meets with the developer(s) to discuss the features to include for the week. The developer(s) help determine which of these priority items will fit into the week’s time box. The developer also works with the team and the growing task list, to identify functionally themed items that should be grouped together either as an iteration or a special project. This effort gives the developer an opportunity to ensure he has enough time to develop things properly, and to develop features with awareness of other coming items that may influence his design for the new modules. Finally, the list is decided and the business stakeholders compile a final iteration document, that outlines the requirements decide upon for that iteration. The developer would take this document and work on the new features Tuesday through Thursday of that week.
On Friday, it is time for the team to begin testing. The developer will have completed “unit testing” and will have checked the critical workflows of the new features, but ultimately the developer is too busy and lacks the objectivity to be accountable for validating his own work. Thus, it is up to the business stakeholders to perform “user acceptance testing” (UAT). During UAT, the stakeholders will validate functionality, using the same iteration document that the developer coded against. This provides a natural checklist to ensure all was accounted for. Additionally, stakeholders should have a “regression checklist” that accounts for all critical workflows in the website or software application, to ensure nothing critical is broken by the new features. Any errors discovered are returned to the development team for repair, and a mini iterative loop occurs for the rest of the day, either until a satisfactory new version of the software is ready for deployment, or until the deployment is called off for that week, due to too many complications, in which case the iteration extends to the following week.
If the “build” receives the greenlight for deployment, this needs to occur at the same scheduled time each week, preferably at off hours. This ensures that any deployment errors that occur, happen at convenient times when traffic is low, and the consistent scheduling helps the developer to follow proper process such as backing up prior to deployment, identifying files to deploy and creating a checklist if needed, which helps reduce errors and increase response time for roll back if something goes wrong. Again, much better than frantically deploying numerous times during a week, in response to the latest “need it today” request. With each additional deployment, risk of a poor deployment multiples and the lack of planning for ad hoc updates adds an exponent onto of that.
By following these proper steps, the developer(s) *and* the organization are setup for success rather than failure. This will not only make the developer happy in the short term, it will result in the entire team having greater satisfaction with outcomes and their relationship with the developer(s) in there long term. Yes it requires a little bit of discipline and advanced planning, but it should actually reduce overall time and cost of achieving the same results; its a classic case of how planning ahead saves time, money, and stress!