Application System Environments

Having properly complete and segregated application system environments is essential when writing and maintaining software in a corporate environment. These environments can make a significant difference in the reliability of the applications systems being developed. In the past, it was not uncommon to have development, testing and production sharing the same environment. With reduced hardware cost and improved server and network technology, it became more common to use safer techniques involving multiple environments. 

Developing or testing software in the production environment creates the risk of introducing unstable and untried code, database changes, or data to the systems that keep the business running. At best this practice will steal valuable resources from the production environment, at worst it can cause catastrophic failure of the application and possible data loss. 

At minimum there should be two environments in use. One for development and testing and the other for production. This setup is not ideal, but is easier to administer and easier on the pocketbook. When developing in a dual environment setup, the development and testing environment can be set up on machines that are less powerful than those in production. 

Ideally, there should be six environments:

The R&D Environment - The R&D environment is a playground for the developers; and is where experiments, "Proof of Concept" projects or prototypes should be developed. Coding is usually based on a designated branch of the code that is used for that specific R&D project. Given the proper hardware and resources, the entire environment should be virtualized; from the development machine to the client machine, to the db server. This virtualization keeps the experimental elements from affecting any of the other environments. If the resources are not available, R&D can be done in the development environment, but more care must be taken to make sure that projects are not affected. Updates should be done to the R&D environments as needed in order to keep the environment as close to production as possible.

The Development Environment - The development environment is where developers do their project work. The code base is usually as much like production code as possible, with the exception of the currently active projects. The development environment can be virtualized, which lends more flexibility to the developer for reworking objects and code that he or she is not happy with. This environment should be as complete as possible, and as close to production in hardware and network setup as possible. In addition to development machines, there should be all needed client machines, file servers, database servers, etc. Updates should be done to the development environment as needed in order to keep the environment as close to production as possible.

The Test Environment - The test environment is where user acceptance testing for a project is done. Any objects moved into the test environment should have already passed internal validation and testing by the development team. From this point on, no new objects or code should be introduced into the environment that has not passed all tests in the previous environment. The test environment should be complete, and as much like the production environment as possible. Ideally it will be an EXACT duplicate of the production environment, but with fewer client machines. The test environment should be refreshed before any updates for user acceptance testing are done. This allows an initial deployment test for the new objects, as well as providing "fresh" data for testing.

The Pre-Production Environment - The pre-production environment exists solely for final deployment testing.  Objects should only be introduced into the pre-production environment as part of a "refresh" from production, or a deployment test. The test environment should be an EXACT duplicate of the production environment. The pre-production environment should be refreshed before each attempted deployment test, so the test is as accurate a simulation of the final rollout as possible. 

The Training Environment - The training environment is a second production environment. It should be an EXACT copy of the production environment to provide the trainers and their students an accurate representation of the work that the user will actually be doing. All updates to this environment should be the results of a "refresh" from production, and should only be done to keep the environment or the data in the environment up to date. 

The Production Environment - The production environment is where business is done, and should only be updated by a thoroughly tested, planned and scheduled deployment. Deployments should include contingency and rollback plans in order to minimize the risk to the environment and the business.

Environments can make or break a development team. Done poorly, the team spends more time dealing with issues or mitigating risks than working on projects. Done properly, complete and segregated environments can help the team develop and maintain reliable systems with minimal defects.

Recruiting

Recruiting is one of the "necessary evils" in the business world. Today's job market is particularly challenging because every candidate is being told how to market themselves and get their "dream job". Unfortunately, there are also no universal truths to picking the perfect new team member. Despite all the challenges that come with recruiting, it can and should be viewed as an opportunity to improve the team in some way.

Hiring for an applications development team is particularly challenging because of many factors: 

• Applications development has become such a diverse field that it can be difficult to spot a candidate with the right skills.
• Application developers tend to be socially challenged.
• Application developers are often arrogant and hard to convince that there are things they do not know.
• Because the industry is so lucrative, there are many people in the application developer community that should not be there.

One of the biggest reasons there is no "silver bullet" solution is because each team is looking for something different, and each team has something different to offer new team members. Some openings have hundreds of applicants, many of which would be a great addition, and the trick is to pick the best candidate. Other openings have very few applicants, none of which are perfect, and the trick is to pick the best candidate. Often, the situation associated with an opening lies somewhere in between, but the recurring theme is the same: the trick is to pick the best candidate.

Recruiting starts with some deep thinking about what is desired in a candidate. Teams vary widely in this regard. Some teams focus on "heads down productivity", where a team member is considered good if they can produce 8+ hours a day of code with a defect rate < 10%. Some teams focus on the "marketability" of its members, where the developer being able to talk to the customer and help sell the product/service is the priority. 

When filling a "senior" role on a small developer team, the candidate should be easy to talk to and able to communicate clearly. They will be required to lead projects, and help formulate standards, processes and procedures so they should have some project management ability as well as a strong method of organization and attention to detail. The team member will have to understand more of the  business, and be able to operate more independently. A "senior" level developer should be someone that can be a backup to the supervisor or manager. Their technical prowess and experience should be advanced.

When filling a "mid-level" role on a small developer team, the candidate should be capable of some project management, and demonstrate that they understand processes and procedures. Communication, organization and attention to detail are very important. Their technical prowess and experience should be significant.

When filling a "junior" role on a small developer team, the candidate can be much less experienced, and their communications skills can be less advanced. The developer should still have a good technical knowledge foundation.

Once the candidates make it past the initial screening, they should demonstrate three main qualities:

1. Ability - Technical ability is very important, though the abilities required and the level of competence with those abilities will vary from role to role. This is also the only one of these three qualities that can be learned.
2. Intelligence - Intelligence goes hand in hand with ability, especially the ability to learn new things. This is one of the most important traits of a technical employee. This quality will let you know how easily the applicant can learn new skills or remain current with their existing skills.
3. Passion - The best technical team members will demonstrate passion for technology. The passion does not have to be directly related to the job, but it helps. A passion for technology leads to the desire to improve ability.

Interview questions should be open ended and vague. The candidate will share more and show more of their intelligence, ability and passion if they are allowed to speak freely. Likewise a poor candidate will often be exposed when they start to stumble.

No matter the size of the applicant pool, technical testing should be devised specifically for the desired role; and should be required of all developer candidates. Thorough technical testing is most important for high demand roles with many applicants, but for smaller teams with fewer applicants, the testing can be more abstract. Large applicant pools will contain more viable applicants and thorough technical testing can often prove the difference between two otherwise equal developers. The ability to learn the necessary technical skills is always more important than the skills the applicant starts with, but having a "head start" can save a lot of training time. In either case, the testing should be observed. The interviewer can learn more from how the applicant works to solve the problem than they can from whether or not the applicant got the answer right. The ability to trouble shoot the problem is as important as the ability to write a good while loop. Likewise, it is very telling to see how a candidate handles the pressure of being observed during the process. A good casual developer will sometimes collapse into distracted incoherence where a cool, level headed applicant may be able to extend the calm demeanor to future meetings and presentations.

Hiring a new team member is rarely fun, but with a little practice and preparation, the danger of selecting the wrong person can be mitigated; and the situation can be transformed from a "necessary evil" into an exciting opportunity.

Requirements

Requirements are one of the most important parts of a project. They form the foundation that the rest of the project is built upon; they define the features that will be included in the system being developed; and they lay out the criteria that determine the success or failure of the project.

Before requirements are gathered, you must identify a Need. In the corporate world, that need is usually dictated by "the business". The Business Need dictates the objective and the purpose for the project. The requirements should all support the Need and should include all features to address the need. A particular Need or project could spawn multiple sets of requirements, but a set of requirements should be related to only one Need. 

The more traditional form of the requirements document contains all requirements in one document. Requirements range from declarations of behaviors, features and the supporting work flows to declarations of the technology that will provide and support those behaviors, features and work flows. All requirements should be clear and concise, and should be easily readable and understandable.

Other teams elect to have two sets of requirements. One set is business requirements. Business requirements are high level and generally phrased as behaviors. The requirements will define a desired feature or work flow items that will contribute to a desired feature. Business requirements should avoid being technical at all. There should be no items that someone who is not technical might not understand. The second set of requirements would be the technical requirements. This document supports and expands upon the business requirements, providing the technical detail that is required to complete the features and work flows defined in the business requirements. Technical requirements do not need to be easily understood by non-technical readers, but should still be clear, concise and easy for someone with technical knowledge to understand. For these teams, all development will result from both documents together, one to define the desired behaviors and features, the other to define the technology needed to provide the behaviors and features.

No matter which method your team chooses, the rules for the requirements remain the same:

1. Define requirements in a declarative fashion.
2. The requirements should be concise and stand without explanation. If explanation is needed, it should be done in supplemental, supporting documentation. 
3. Requirements are not about implementation. Implementation plans and details should be saved for the design document.
4. Each requirement should be prioritized. If the project gets to the point that some features cannot be implemented, it helps to know what gets trimmed out first.
5. Each requirement should be:

• Correct – it must accurately describe the functionality to be delivered
• Feasible – it must be possible to implement each requirement within the scope of the project.
• Necessary – it must fulfill a true need.
• Unambiguous – it must have only one interpretation.
• Verifiable – there must be a way to test it and tell if it has been implemented correctly.
• Understandable – it must be written in a way that does not require specialized knowledge to understand.

Requirements are nothing to be afraid of. They do not have to be hard, nor complicated, but they will often set the tone for the project to come. 

Losing a Team Member

Every team experiences loss sometimes. My team is losing a member, and it has prompted contemplation of what it means to lose a team member.

If you have spent any time in the corporate world, you have seen team members come and go. When a team member leaves, whether it was their idea or not, it will usually fall into one of 3 categories:

• "How will we survive without them?" - This usually happens when it is a team member that is considered key. Their skills, knowledge and/or experience makes them a crucial part of the team. The team, colleagues, clients, managers and customers wonder how things will work without them. There is always some speculation of whether or not the team or business will survive without this crucial member.
• "I am happy for them" - This is the sentiment for a team member that was good or great, but did not have that "something extra" that made them crucial. The team, colleagues, clients, managers and customers wish them well and regret the loss, but quickly move on. The loss can be considered "painful", but is not generally met with much concern or fan fare.
• "Could see it coming" - Sometimes there is a team member whose leaving makes the team better. This improvement is sometimes not clear until that team member is gone. For example, they may be a drain on morale, but not be doing anything that warrants disciplinary action. Sometimes they just do not "fit in". Losing these team members will have much less negative impact on the team, and will often have a small positive impact.
• "Thank goodness they are gone" - In the worst case, there is a team member that cannot be fired fast enough. They are a burden to the rest of the team and cause more problems than they solve. These are the team members that get a "goodbye party" thrown AFTER they are gone.  

No matter which situation applies, losing a team member will present some challenges:

• Schedule interruption - No one adds time into their schedule for losing a team member. The time involved in transitioning the lost member's project(s) to other team members is more than enough to throw a kink in any schedule.
• Knowledge/skill loss - Every team member has knowledge and/or skills that are unique. Transferring or compensating for those skills is can be difficult. Often "alternative solutions" will be needed.
• Replacement - Recruiting and hiring is often an arduous, difficult process. This gets even more complicated when replacing a senior member of the team. The more senior the lost member, the more "shake up" will be involved with replacing them.
• Psychological affects on the team - Often when a team member leaves, it causes remaining team members to question their commitment to the company and/or team. Team members can feel angry at the situation surrounding the loss; they can be seduced by opportunities not previously considered; or they can be worried about their standing within the team.

I have witnessed all of these situations at one point or another in my career, and while the details of each occurrence is different, there are certain universal truths:

• The company will survive - No matter how painful the loss of a key team member may be, the team and the company will survive. If losing one team member, no matter how crucial, kills the team or the company, then there were bigger, more important problems.
• The loss should be used to the advantage of the team - Every team has some processes, procedures or environments that should be improved, but have not been for some reason. The loss of a team member, especially a key team member, can be the catalyst for change that the team needs. On the few occasions that my team has lost someone, I have used that loss as an opportunity to improve the team's processes, procedures or environment. Even the most reluctant VP is often more willing to agree with, "While the team's efficiency will suffer during the recruitment process, the impact can be minimized by <insert team need here>."
• Team members should view the opening as an opportunity - The best view of what the future may hold for someone is how they handle adverse situations. The loss of one team member may be an opportunity for another team member to shine. Learning something new or accepting more responsibility can be an indicator that a team member is ready to move their career forward.

In short, losing a team member is NOT the end of the world. Sometimes it is worse than other times, but in the aftermath, a good team will survive and sometimes even prosper.

And so it begins...

I have been thinking for quite a while about starting a blog, and the time has come.

The purpose of my blog will be to share my experience with the community. I will discuss topics that have come up in my work as the manager of software developers in a national insurance corporation. My intention is to provide advice and opinions from my experience on topics such as: New Technology, Development Processes and Procedures, Developing the Team, Managing the Team and Surviving Corporate Life.

Why am I qualified to give advice and opinions on these topics? I am not entirely sure that I am. I have been developing software since 1979. I started with a TRS-80 and "trash basic" in the 3rd grade. I tried it out in a class and my life changed. I have had a passion for computers, technology and software since. I have learned untold number of languages over the years, and equally as many patterns and techniques. I have been in the professional world since the early 90's, and have worked for companies that range from LARGE banks to a consulting company with five employees including two and a half developers (one was part time). I currently work for a mid-size, national auto insurance company. My responsibilities have ranged from humble beginnings as a help-desk tech through a few ups and downs to my current position as the supervisor of a six man development team where I act as the architect, project manager, and design and development supervisor.

I am always open to constructive criticism, and am willing to consider points of view other than my own. I have learned that good honest debate is sometimes the best way to learn something new.

And so it begins...