The Importance of your Development Context
Posted by robkraft on August 9, 2011
Development context places the primary constraints on the priorities of product development. As a developer, you can provide more satisfaction to your users when you understand the development context you are working in. Some developers are not even aware that context exists and that context makes a difference. These developers can be found at local user group meetings and on forums adamantly declaring that their approach to solving a problem is the only right approach. But development context is important and it does influence the best approach to solving problems. An extreme context example is the difference between developing the software that keeps a person on life-support alive, and developing software for your personal use to keep track of your collection of rare coins. I’m sure you can identify many aspects of the development process that will vary between these two extremes.
Both development teams and projects have a context. Most often, the context for the development team and every project is the same, but occasionally the development team may be thrown a project that needs to follow a different context than their usual development. Being aware of the different context opens team members to new approaches to solving to the problem that may be more efficient than the usual development process, and that may provide a learning opportunity.
I have thought of a few contexts that influence the development processes:
- Quality versus early to market. In some contexts it is more important to release features to market, even unfinished or unpolished features than it is to provide a robust, bug-free, fully-featured product to the client. Quick to market features sometimes help eliminate development waste. How so? When you don’t bother to spend the time to polish a feature (spell-check, languages support, tab orders, font sizing support…) and then you discover that clients want the UI to look a lot different; you have just saved the time that you would have wasted polishing a UI.
- Some development teams develop core business applications year after year, but then receive one project that is different. Perhaps it is a one-time program needed to collect and report on some data, and then the program will be thrown away. Perhaps the program is only used by one individual. Such a program may not need the same level of Q/A, documentation, user testing, auditing, logging, security, etc. as the core business applications. This is another example of context difference impacting development architecture and processes.
- Another aspect of the development context is the attitude toward new technology. There is no correct attitude, but each attitude has its benefits and drawbacks, and each project and development team should clarify the attitude for each project. By attitude, I am referring to the choice between using tools, techniques, and processes that you are familiar with, that are more predictable, and that incur less risk OR choosing new tools, techniques, and processes in order to keep up with the times, take advantage of ways to improve quality and speed development (usually after a learning curve). Some teams strive to stay on the cutting edge, others prefer to make no changes, especially to valuable stable core business products, and some teams prefer to limit their pace of technology adoption to the things offered by their main technology provider such as Microsoft.
- Occasionally self-education and learning affect the processes, architecture, and tools used for a project. Some examples include implementing a project using SCRUM when your normal development process does not use SCRUM. Using Test Driven Development (TDD) is another example. Using a new DBMS or programming language can affect your context, as can a switch to using IOC containers, MEF, MVC, or MVVM. When part of the project goal is to learn something new, it can reduce development speed and introduce quality defects. Project managers should be more tolerant of quality defects and deviations from the usual development processes as new good practices are discovered in response to the changes.
I think it is worth repeating that the development context affects a lot of things, particularly requirements gathering, quality assurance, documentation, user testing, application logging, application security, application auditing, and more I’m not thinking of.
What else do you know that alters a development context, and thus the way we develop the software?