Architectures for Good Software Testing – Part Two (Development Environment)

One of the most important issues with development environments is “gold plating”. To put it simply, this is when the developer tries new technologies, or approaches to make his job more interesting or challenging. If the enterprise does not allow the individual developer to learn and expand their knowledge they will have an unacceptable high turn-over on their development team. As we all know, replacing a developer in the middle of a project is much more expensive in development and quality assurance hours than a dedicated physical development environment.

The second most important issue with development environments is the simple fact that stuff happens. Anything can happen during any time during

Stuff Happens - Plan On It!

Stuff Happens – Plan On It!

development. The code may run perfectly well on individual machines but when it is combined as one application on the development server, things can blow-up quickly and max out the processor no matter how many virtualized environments you have. If the CPU maxes out, it’s lights out. On servers where developers and quality assurance teams work together, both teams will be down until the bad code is identified and rolled-back. The expense of two teams completely off line is very painful. Creating shortcuts by trying to save on environmental segregation is a sure way to push your project over budget and possibly loose good team members.

Finally, by giving the development team their own physical server they can “cut it up” any way they wish by creating as many virtual environments as they wish. I recommend asking the development team to put both their application and database servers on the same physical server. I prefer to have the machine a bit “under powered” as well. This helps the developers keep performance in mind. Inexperienced developers often believe since processors today can do more, they should give the processor more to do. If his code will not run because the machine is a bit weaker than desired, he is forced to compensate by writing more efficient code. This may sound like a manipulative back door maneuver, but I can assure you if performance is not kept as a major consideration during development you will soon have an application that will not run even on the most powerful and well configured servers. Setting clearly defined performance benchmarks is a normal part of the quality assurance process, but you will have less issues with performance if the development server is, within reason, underpowered.

Click here for part four – “Quality Assurance

About Larry

Larry Lawhead is a passionate Agilest with a love for coaching, mentoring and organizational transformation. Huge fan of the Lean Enterprise, LeSS, Theory of Constraints, systems thinking and of course the Toyota Production System. Avid learner. Deeply influenced by the works of Jeff Sutherland, Eliyahu Goldratt, James Womack, Craig Larman, Faith Fuller, Marita Fridjhobn and countless others. He is likewise a member of the team that brings the Agile Open to the Southern California. Above all else, he loves coaching teams and individuals. He believes creating a safe and empowered place for individuals and self-organized teams to develop brilliant solutions, shared vision, demonstrate compassion and desire to continuously improve brings life’s greatest rewards. Watching clients unfold into a greater sense wholeness, purpose and direction is the miracle coaching enables. This satisfaction leads to continuous self-improvement, curiosity and personal growth that Larry passionately embraces.
This entry was posted in Architectures for Good Software Testing, Quality & Value and tagged , , , , , , . Bookmark the permalink.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.