Crookshanks - Practical software development techniques : tools and techniques for building enterprise software

APPENDIX A

Enterprise Considerations and Other Topics

There are several factors that differ in an enterprise environment from an educational environment. Depending on the size and structure of the university or college some of these factors may be experienced to some degree. We will briefly list these concerns from a large organizational perspective and how each impacts or influences software development. We also discuss some general topics related to the software development career.

These topics may also be used to form the a basis for some interview questions when the interviewer asks Do you have any questions for me? asking a question based on one or more of the following topics can show that you are thinking in a large organization frame of mind.

One final disclaimer the discussions in this section are based loosely on the experiences of the author and several of the authors colleagues; software professionals with an average of 15 years of experience. This means most of us have seen the dot-com boom, bust, and what has happened since. Most have been in large organizations (hundreds or thousands of employees total), micro shops (3-4 developers and a dozen total employees), and all sizes in between. Employment trends, technology trends, and business practices constantly change, so the discussions forthcoming should not be taken as an absolute predictor of how technology employment will be like, only as a general survey of some topics that are not often discussed in an academic setting.

Number and Location of Team Members and/or Users

In large organizations and todays job climate it is becoming more and more common for team members to be geographically dispersed. Several factors influence this trend non-local company acquisitions, availability of talent in specific areas, cost of real-estate, and even security. Collaboration tools such as GoToMeeting and Microsoft Live Meeting make distributed team communication easier than ever; webinars and other distributed learning technologies reduce the need for travel expenditures. All this increasingly means that companies are becoming more and more willing to find talent wherever it is located rather than insisting it be local to the company.

Likewise, end users can be located just about anywhere. For business software locations such as New York, Los Angeles, and Hong Kong are important. This has to be taken into account for not only software response times (such as a user in Hong Kong receiving a file from the States or calling a web service based in Omaha) but for software maintenance as well. Upgrading a system at midnight Eastern Time is noon in Hong Kong; Asian users may be slightly upset if there system goes offline in the middle of their business day.

Game programmers are especially affected by distant users. Increasingly, multi-player games can be attended from anywhere with a wide range of broadband speeds and response times to factor in. This could have a huge effect on performance and must be taken into account. The important thing is to remember this when developing and testing and to attempt to simulate remote users with built-in delays, random communication failures, etc.

System Integration

Unlike legacy client-server systems, most :, systems may have to interface with other systems via web services, remote method calls, DCOM, or some type of messaging. This has profound impact on applications, for two main reasons. One, there is a possibility that the external system may be unreachable for some reason. And two, the external system may change its interface or data format without proper communication. Error handling, retrying, and alternate processing strategies are very important when dealing with external systems. Also, designing systems via dependency injection allow for testing of these interfaces without actually connecting to them. This allows both for positive testing (aka happy case), when communication goes right, and for negative testing, or simulating when communication goes wrong.

Separation of Duties and Environmental Limitations

In larger software organizations there are typically several stages software goes through before being released to the customer, internal or external. These different stages will have different limits on how software developers can interact with each environment. The reasons for this separation are very diverse. In some cases, such as retail software, there is no way to provide developers access to end users desktops, so production access is a moot point. In other situations where the customer is an internal user, production access for developers is limited for security and risk reasons. The time card application from the last chapter is a good example of an internal application where access to production needs to be restricted; both for security of personal information and the possibility of fraud. For the following discussion the assumption is an internal application that is never seen by users outside the organization but still has sensitive data. This could be human resources software such as our time card application or an application that processes outside user data but isnt seen by them directly - a policy analyzer for an insurance company for example. In this situation, many organizations will have a minimum of three different environments for the software development, testing, and production.

In development, software developers may have complete access and authority to their application. This usually includes the right to install and change application code, run tests, browse logs and directory configurations, edit files, etc. However there could be restrictions on what is allowed to be done or tools to be used; not so much for the development environment itself but to align the system with what is allowed or prohibited in the higher environments. So even though a developer can change application code, they may not be allowed to apply service packs or patches to the operating system.

Development environments are also typically matched with development areas in supporting services, such as a database or a messaging system. And although software developers may have elevated privileges to these supporting environments (relative to production), they are still most likely owned and managed by different teams. Although privileges are greater than the higher environments there could still be limitations. For example, a software developer may have rights to execute certain SQL statements in the development database, such as creating a table, but would not have permission to create the actual database. This would be restricted to the database team and any database creation would have to be requested.

The testing environment is probably the most diverse area in terms of developer rights. In some organizations testing is only slightly different from development; developers have rights to install software and review logs but cannot edit files or directory structure. Developers may also work directly with individual testers to step through testing and fix defects (bugs) on the fly. This could pose a problem however if the developer is not diligent about keeping the code in development up to date. Many organizations have deemed this strategy too risky and no longer operate in this fashion.

Many organizations now treat the testing environment as pre-production and allow very limited or even no developer access. In these cases dedicated support teams would use installation programs or other tools to install the application and the developer would have no access to tweak the installation, directly review logs or files, or modify code. The users at this stage are the Quality Assurance (QA) team; the group that takes the original business requirements and exercises the application to ensure all the requirements are met. They would test the application for a specific period of time, and then produce a list of defects. This list would be given to developers who would work on them in the development environment before having the code re-installed in the testing environment. In this process it is important that the code remain unchanged while the testers are testing because they are in effect simulating end users.