With the current economy it is important to know what will help you keep you current job or easily get a new one if you need to. Here are my tips for recession proofing your development career - let me know if you have any other suggestions!

1.    Have a positive attitude. When a manager has two developers with equal technical skills but one is optimistic/"can do" and the other one is grumpy you can bet that grump will be laid off first.

2.    Keep your promises. If you promise to complete a piece of code by Thursday make sure than you do. If you don't think you can make a deadline it is much better to speak up ahead of time and renegotiate what can be done, or get help, rather than say "yes" when you are not sure. If you have agreed to a deadline and things change tell your manager or client as soon as you know, so that you can both come up with a  plan B.

3.    Keep your code simple. Simple code is easier to read and maintain, generally runs faster and has fewer bugs. Clever code has a way of biting you or someone else in the rear end. Yes it sometimes takes more thinking to write something simple and elegant instead of complex -- and your future self will thank you for doing it!

4.    Communicate clearly. The number one way projects fail is poor communication - misunderstandings with clients over scope, missing features, upsetting email threads. Confirm verbal meetings afterwards in bullet point emails. If a topic is getting heated in email then switch to an in person meeting or phone call to defuse it, then document what was agreed in email afterwards. Keep your ego out of the office and out of your code. Focus on what is best for the project and client.

5.    Bring up questions early. If you get stuck on some code (and who hasn't some time or other) then bring up questions early. There is nothing worse than a late deliverable that could have been on time if the right questions where asked sooner. If being assertive doesn't come naturally to you read a book or take an evening class on assertiveness.

6.    Don't add bells and whistles. If the client has not asked for a feature don't add it without asking first. Maybe they really like the idea and will pay extra for it. Maybe they would rather wait until version 1.0 is released before adding the feature. Maybe it is not of interest to them or the users at all. In any event you are better off asking before adding features that are out of scope.

7.    Test and proof read your code. Clients and managers can not directly tell how good your code is but they sure can see when you have a bug! Test your code every time you make a change - there are no changes too small to test! The other thing that clients will spot is typos and spelling mistakes - I know that it is not fair but they will initially evaluate your code based on how it looks, not on what is does under the hood. If you can't spell well or don't have a good eye for user interfaces then get the help of someone who does to give your application a proof reading before you send it to clients to review.

8.    Keep Learning. Technology is always changing and companies keep those who have the most upto date skills. Read books on evelopment, follow blogs, attend user group meetings and go to conferences. And if you do have to find a new job it will be easier if you have CF 8 and Flex experience on your resume.

9.    Network. If a developer has amazing skills and a great attitude but no one else knows them then it will be hard to get a new job. You never know who may refer you to work in the future. Go to user group meetings and talk with others, help others out on lists, attend the networking events at conferences, trade business cards. Focus on what you can give to others and then you will receive in return at another time.

10.    Volunteer. A great way to stand out is to volunteer at your local user group, conference or company committee. Speak, write or blog. Just be prepared to do this on your own time. Consider it an investment in your future.

Attending a conference such as CFUnited will let you learning new skills, learn better project skills and network with more people than you could meet in 2¹⁰ days at home!

This is a continuation of the TeraTech Development Approach from last month.

7. Develop Common Web Services

One significant advantage of moving applications to the new version of ColdFusion is the opportunity to reuse code and share common services between applications. It is possible to build and deploy components such as a common security access management tool that will serve all agency Web applications. As new applications are added to the platform their business and data functions will be examined for possible use as common business functions availabe to other applications.

8. Testing

The integrated Fusebox-based application system is extensively tested and debugged to ensure that the system produces the same results as the original system. Where possible, the legacy system test plan is used for testing of the new system functions. We use the Rational testing tools, including Test Manager and Rational Robot to facilitate and document our test cases and results. These test plans are comprehensive for the new and converted systems and will be re-usable in the regression testing of futures releases of the software.

This is a continuation of the TeraTech Development Approach from last month

5. Web Site Design in Fusebox

The system methodology used for NJ Sullivan development is Fusebox 4.1 running on ColdFusion MX version 6.1. The design model to be employed is the Model-View-Controller (MVC) pattern.

With Fusebox and MVC there is a separation of the data from the presentation and business rules. A plan for the Fusebox model is developed from the form prototype by the system architect.

Detailed module functional requirements are prepared by the architect using the standard Fusebox "Fusedoc" model. (www.fusebox.org)

6. Develop Database Access Components

During Web site construction the data access model is tranlated into database access components using ColdFusion components. These data construcs enable the re-use of common data queries and update logic by all system functions.

This is a continuation of the TeraTech Development Approach as continued from last month.

4. Web Form Prototype

If all system requirements are encapsulated in the existing model, a prototype can be developed directly from the legacy forms and reports. A model of the system functions is prepared in HTML to illustrate the proposed form flow and processing.

The prototype contains no dynamic data. All data displayed is hard coded on the source forms. All links are local HTML forms that enables the demo to be executed on any computer with a browsers. The following features were implemented in this prototype:

-Develop a "wireframe"(skeleton view) of the system forms

-Select style sheets from the available set of NJ Sullivan style sheets that will support a general look and feel and be acceptable to the end users.

-For legacy systems, copy and imitate the layout of the existing system menu structure and forms.

-Attempt to copy the layout and flow of existing legacy forms where appropriate, recoding for section 508 issues.

-Employ common Web navigation patterns when the legacy form flow was inappropriate for a Web site. This results in minor changes in process flow due to the introduction of additional forms to simplify form processing.

The Web mockup is presented to the users for comment and correction. Since the Web site has been modeled on the legacy system form flow users are able to quickly understand how the proposed system will work. User request for changes or enhancements are made to the HTML prototype and agreed to before system development begins. The process of review and modification typically requires at least three iterations.

The Prototype becomes the basis for user acceptance of the new system design and function. The NJ Sullivan Task Order Managers can used the prototype as a benchmark for the identification of the formal requirements for the system. Based on the prototype the system architects are able to document the formal requirements artifacts needed to document the planned system, to develop system decision and flow diagrams, and develop accurate schedules for coding and deployment. It is also the model for he development of the formal system test scenarios.

This is a continuation of the ongoing TeraTech Development Approach from last month.

3. Database Review

The data structures from step 1 are reviewed by the architects to determine if any redesign is required for the new system. The following factors will be considered:

-Normalization of the data structures

-Change the databse platform (ie convert from MS Access to SQL Server)

-Data cleanup or correction

Conversion and data correction plans are prepared based on this analysis and then discussed with NJ Sullivan Database Administrators (DBA's).

This is continued from last month in a continuation of TeraTech's Development Approach

2. Discussion with users to review these artifacts produced in step 1 results in the discover of unneeded system functions and begins the process of identification of the new functionality missing from the legacy system. It is not unusual to find that the legacy systems are fairly complete models of the functionality needed in the new system.

Unless the users are significantly displeased with the presentation flow of the legacy system a new model can be developed from the legacy data and forms very quickly. Where users need new functions or major revisions to the legacy system flow, methods for New System development are employed to discover how those functions should work.

This is a continuation from last months discussion on Application Architecting, FuseCoding, Unit Testing, Application Integration, and Deployment in TeraTech's Development Approach.

The TeraTech methodology centers on the practice of documentation of our work and the placement of all development artifacts into a repository along with the source code.

1. System Decomposition

-Capture all system froms using a screen to capture and saved as BMP images and printed for analysis. -Map the form hierarchy for the system in a graphical tool such as Visio. -Reverse engineer the database -- Microsoft Visio is used to capture the tables and re-construct the relationships in that data. -Examine the SQL queries and identify business rules. -Review user guides fro system functional requirements. -Review system test plans for verification of system operations.

Various system diagrams and processing state diagrams are developed to clarify how the existing system functions.. Formal design artifacts will be developed, such as use-case diagrams, state management diagrams, and action diagrams when appropriate for discussion of complex business functions.

This is a continuation from last months installment of the TeraTech Development Approach.

6. Unit Testing

As each fuse is coded, it is unit tested against the test harness. This gives the coder a way to ensure the correct behavior is produced by the fuse, without being in constant contact with the architect.

7. Application Integration/Final Testing

As the fuses are completed, they are returned to the architect, who integrates them into the final application. Daily builds are employed, gradually transforming the prototype into a working application.

After developer system integration testing, the new release is deployed to the NJ Sullivan center for final user acceptance testing following standard NJ Sullivan testing procedures.

8. Deployment

Deployment is the least exciting phase of the FLiP project. Thanks to the high degree of communication between the client and architect, and the architect and coders, deployment should hold no surprises for anyone.

This is a continuation from the ongoing discussion of TeraTech's Development Approach.

4. Application Architecting

Once the prototype is finished and approved by the system owners, the application architect constructs the application design or schema, identifying fuseaction and organizing them into circuits. Each fuseaction's behavior is broken down into a set of fuses, and the architect writes a Fusedoc and a test harness for each fuse to be produced. Once the design has been constructed, coding can begin.

5. FuseCoding Each coder employed on the project is sent one or more fuses and their corresponding test harnesses. The coder writes each fuse according to its Fusedoc. By using the Fusebox framework, the coder's work does not rely on the rest of the application. Each fuse can be coded and tested on its own, and can be plugged into the rest of the application. This step can be accomplished by one coder or many coders.

This is a continuation of the series in TeraTech's Development Approach from last month.

3. Prototype/Front End Development

A FLiP prototype is a clickable model of the finished application with dummy data and no backend behind it. Prototyping is the largest stepn in the FLiP cycle, generally taking up to 70% of the project's elapsed time for new systems. The result of prototyping is something that looks exactly like the finished application, with no functionality just client side screens. The objective is to discover exactly what the client expects from the application, and how they want it to look.

Prototyping is typically done in plain HTML. The finished prototype will become the application's user interface, so the traditional sense of a prototype being a minor, throw-away version is not the case. All the effort made in this step is used in the final application.

The Prototype becomes the basis for user acceptance of the new system design and fuction. The NJ Sullivan Task Order Managers can use the prototype as a Benchmark for the identification of the formal requirements for the system. Based on the prototype the system architects are able to document the formal requirements artifacts needed to document the planned system, to develop system decision and flow diagrams, and develop accurate schedules for coding and deployment. It is also the model for the development of the formal system test scenarios.