Developer Types - An Introduction

There are many types of software developers, and if you spend enough time in the industry you will meet them all. There have been posts in many blogs about different software developer and/or programmer types, and most lists have some similarities. However, personal experience affects your view of the stereotypes. I will spend the next several posts discussing the stereotypes that I have seen.

The developer types as I see them are:

• The Cowboy Coder – the amazing lone wolf
• The Young Buck – wants to write his own operating system
• The Work horse – reliable and steady wins the race
• The Code Monkey – needs specific instructions
• The Developer – winner of the all-around
• The Layover Coder – just a step on the path
• The Good Enough Coder – “Just the task, ma'am”
• The Over Optimizer – nothing is good enough... ever
• The Original Coder – older and often nostalgic
• The “On A Tangent” Coder – easily distracted and often off topic
• The Adamant Caveman – unwilling to change and happy with the way things have always been.

As most developers, I have some traits of each of these types, and have occasionally been firmly seated in one type or another. In the immortal words of Dr. House, M.D., “It is a stereotype for a reason.”

Strategy v Tactics

Strategy v. Tactics

In the military, tactics is all about winning the battle. It is about what is happening locally and “right now”. It is about completing the mission; about squad deployments; and about the survival of the team. Envision the “LT” crouched quietly behind a tree, making hand signals and deploying his troops to out maneuver the enemy that has been spotted farther down the trail.

Strategy, on the other hand, is about winning the war. It is about battle plans, large scale troop deployment and survival of the cause. Envision the smokey WWII war room with communications equipment around the perimeter and a giant map in the middle. The generals stand over the map, contemplating the whole war, moving the little figures of men, tanks, planes and ships around with the croupier stick*. Battles are won and lost, but under the proper strategic guidance, more battles are won than lost and ultimately that leads to winning the war.

Military success takes great leaders in both the tactical roles (battlefield commanders, non-commissioned officers, etc.) and the strategic roles (Generals, Admirals, etc.). Battles cannot be won without the former, and successful battles have little meaning without a coordinated vision, led by the latter.

In the corporate world, tactics and strategy are also very important. IT tactics are lead by the managers and team leads. They set short to mid-term goals, usually in the form of task assignment, project management and team management. The tactical leaders are responsible for the design and coding standards that make projects successful and keep the day to day operations running smoothly. They also set team processes and procedures that ensure long term tactical success and support the strategic vision.

IT strategy is lead by the executive management team, which is responsible for long term goals and “the big picture”. They set enterprise processes and procedures that help make the teams successful and keep the department running smoothly; as well as setting enterprise architectural standards that help set the framework for continued success. The strategic leaders make sure that the tactical battles have purpose and serve a common vision.

As with military success, business success takes great leaders in both strategic and tactical roles. Instead of Generals and Admirals, the business has CIOs and Vps; and instead of battlefield commanders and non-commissioned officers, the business has managers and team leads. While lives are not hanging in the balance with each business decision made, success hinges on the skills and coordinated efforts of the strategic and tactical leaders.

* I only know it is called this because my brilliant wife Googled it!

True Geekwards Reboot - Everything Else is Rebooting, Why Not This Too?

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

The purpose of my blog..."

Almost a year ago (8/13/11), this was how I started. I managed to get 6 posts out in a little over a month. I underestimated the time and effort that would be required to create this blog, especially since I committed to posting complete, pertinent, well thought out material. Despite the extra time and effort I had to put in, I was enjoying the activity and happy with the product.


THEN LIFE HAPPENED.


The team experienced more turn-over than we have had to deal with for quite a while. My Business Analyst (and "right hand man") resigned to pursue an opportunity with another company. One of my developers resigned to go to Space X (it is hard to fight something like that). We gained a couple of people, we lost a couple of people including my manager and most of our "development support" staff. Mostly normal turn-over kind of things, but stressful, nonetheless. Overall, I think the team has weathered it well, and learned from the experience.


We also suffered through: some production system challenges that meant long hours and tons of pressure from the business; reworking of some of our process and procedures to accommodate tactical and strategic IT plans; and a workload that is hard on a small staff with limited resources. 


Despite these stresses and challenges (or possibly because of them), some good things happened for my personal career. When my manager resigned, and I was promoted. This meant that for a time I was responsible for all my team lead duties, all my supervisor duties, AND all of his duties. It was a new challenge and I worked through it, finding a way to make it all work and adjusting my work load and work flow to accommodate. Going from "doing" to "delegating" is a very hard thing for people like me. It was not easy on me, my team or my family. But, as I often say, "If it was easy, ANYONE could do it!"


I am always my worst critic, and the things I could have done better often stand out more in my memory than the things that I did right. I must have done more right than wrong though, because 6 months later I was promoted to Director of Application Services. I have no doubt that a significant factor in my recent elevations has been "being in the right place at the right time", but as I become more comfortable in my skin as a member of management, I can tell that my skill and ability is increasing. And my focus remains on further improvement and stretching to meet and exceed expectations; expectations laid upon me by the company, as well as those laid upon me by myself. I am also currently working on my PMP, and have been offered a spot on the Computer Science & Industrial Technology Advisory Board for Southeastern Louisiana University.


So.... with all these things happening, the blog did not. I thought about it often, more in the last few weeks than ever, but just never actually sat down and worked on it. I have decided to re-commit to writing, and so my first new post is a reboot, a "what happened to the blog" post as well,  as an update to my first post.


From post #1 (with updates in italics):
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 manager of a six man development team where Director of Application Services. I am responsible for a development team that is currently under-staffed at 4 developers, but will have 7+ developers when fully staffed, as well as development support staff of QAs and BAs. I act as the architect, project manager, and design and development supervisor, IT project governance and strategic advisor, IT recruiter, coordinator of efforts between multiple development teams, lead business analyst, lead quality assurance analyst, and many other things.

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 (again)...

Successful Projects

The first step to determining success is defining success. Every project should start with some definition of success. The definition may change over the course of the project, but there should always be a way to determine that the project is moving toward a good conclusion. One of the biggest challenges in the definition of success is making the definition realistic. If the definition is too lofty, success will be impossible. Avoid things like "bug free", as well as things that are impossible due to time or resource constraint. If success is unattainable, then the only other possibility is failure.

Some common elements of success are:

1. It works - Remember that the most important thing for any project is that it works. This should be the first item of any definition of success. If it does work, no matter the status of the other criteria, it is at least partially successful. If the project does not work, it cannot be a success. 
2. It is easy to support - An important aspect of most projects is that it be easy to maintain and modify. This will be important in reducing risk to future enhancements.
3. It is responsive and efficient - A project that works but is too slow will be considered unusable. Determine how responsive and efficient the application must be, and use that as a success element. 
4. It is user friendly - If the UI is to "clunky" or does not work in an intuitive way, users will not want to use the application. An application that the users don't like to use can be a bigger failure than one that never existed.
5. It uses "cool" technology - An important part of maintaining an application is having developers that are happy to maintain it. Using the right patterns and methods can go a long way toward keeping developers excited about the project. Using the right technology can also increase the chances of success in the other criteria as well. 
6. Project specific successes - Most projects will have a set of success criteria beyond the other items listed here. They should be included in any assessment of success.

All of these should be specifically qualified for each project. Some projects may not require a UI at all, for example. Temporary projects may have much more importance assigned to the "it works" category than to the others, but keep in mind that few projects are ever as temporary as first intended. Care must also be taken not to spend too much time and effort on gains that are insignificant.

Managing risks can also determine the success of a project. One of the biggest risks to any project is scope creep. Scope creep is caused by changes to the plan. The plan can be changed on purpose, due to a change in priorities or a change in information about the project. These changes may be necessary, but should be carefully considered and tracked. 

The plan can also change because of loss of focus. If the team gets distracted from the overall goals and vision of the project, they can spend a significant amount of time on activities that are unimportant or unnecessary.

Managing scope creep is one of the most difficult parts of many projects, and one of the biggest keys to success. 

Management of the effort and resources put into a project is very important as well. If more effort and resources are spent on the project than the results justify, then even a project that meets all the conditions for success is not truly successful.

There are several things that can be done to maximize the chances of success. 

• Good requirements - Requirements that are declarative, concise, focused and prioritized will help set the definitions of success, as well as starting the project with a solid foundation. 
• Good team - A team that is competent, focused and united will increase the chances of a successful project. 
• Good marketing - Whether the project is to be sold commercially or used internally in a corporation, good marketing is important. Evangelizing the project will increase awareness and excitement for the system. 
• Good documentation - Documentation can help in many areas. It helps measure success, helps keep the project on track and helps keep all the interested parties working together well. Documentation is absolutely essential to successful maintenance of the system.
• Good plan - A proper plan will give the team members an understanding of the need being fulfilled and an understanding of the solution being developed. The plan should include thorough, trustworthy design, good development practices, thorough testing and a plan for implementation. Most importantly, the plan should support the larger vision for the affected systems.

One of the most important decisions about a development project is when and how to end it. There are several fates that can befall a project: it can be abandoned as a failure, it can be postponed for future review or it can be declared a success and moved into production. A failed project is one that has not met enough conditions of success, and the investment required for any path forward is more than the project is worth. A project that has met some conditions of success, but requires investment of time or resources that is not currently available can be postponed until the time and/or resources are available to complete the remaining success conditions. A project that meets enough success conditions to be moved into production is completed successfully, ending the "construction" project and putting the system into "maintenance" mode for future modifications and enhancements.

Proper risk management and definitions of success can increase the impact of any system. Following good, consistent, easy to understand processes and procedures will benefit any development team. In the end, each team is different and must develop it's own processes, procedures and definitions of success, but the most important thing is that these things exist.

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.