• Do you have issues with scope creep or requirements?
• Are you concerned about users accepting your new apps?
• Do you want protect your organizations reputation for quality on the web?

Then join us for this free webinar with TeraTech's Michael Smith and learn seven ways ColdFusion projects may fail and what to do about it.

In this webinar we look at seven different ways ColdFusion projects fail - from outright disasters, through project deadmarches to more subtle forms of failure that you might not notice until it is too late. By learning how projects fail and what to do about these issues you stand a better chance of having your projects succeed!

"I have occasionally been tempted to adapt from Anna Karenina and note that happy software projects are all alike but each unhappy project is unhappy in its own way. On the other hand, some of Tolstoy's critics do say that he got it quite backwards and that the bad stuff is very predictable." - Anonymous CF Project Manager

We will look at the following issues (and ways to solve them!)

• Scope creep and requirements
• Buggy peopleware
• Lack of user and executive management support
• Poor planning and milestones
• No vision and objectives
• Incompetent Staff
• Poor testing and deployment practices

This webinar is with Michael Smith, CEO of TeraTech, a ColdFusion consulting and server tuning company founded in 1989. Michael has presented at over 50 conferences and user groups and written over 20 articles on ColdFusion. He started the CFUnited conference and ran the Maryland ColdFusion User Group for many years. Connect on LinkedIn with Michael

TeraTech delivers custom ColdFusion apps on budget and on time every time. We ask the right questions, bringing issues to light immediately and break projects down into manageable pieces. We pride ourselves in writing code to standards and doing developer code review to ensure the quality and simplicity of code. The goal of every project is to hand over a program that is maintainable and sustainable by our clients. Our ideal client is an organization with over 100 employees and has ColdFusion apps that are built and faltering or need to be built. They appreciate outsourcing work to take advantage of an outside perspective and talented developers to get projects done quickly.

When a ColdFusion project is out of control or going to miss its deadline, we are brought in to put out the fire, get the project on track and get it finished on time. When a ColdFusion server crashes, we are called in to resuscitate it and bring it back to life. (Ideally, we are brought in before crashes happen!). Follow us on LinkedIn

The webinar on "7 ways ColdFusion projects fail" is on Wednesday, May 1st, 2013 1:00 pm - 2:00 PM EDT. The webinar will cover seven ways ColdFusion projects fail and what you can do about it. It will be approximately 60 minutes including time for Q and A. The webinar is free. You can register at https://www1.gotomeeting.com/register/643109128 See you there!

System Requirements
PC-based attendees
Required: Windows® 7, Vista, XP or 2003 Server

Mac®-based attendees
Required: Mac OS® X 10.5 or newer

Mobile attendees
Required: iPhone®, iPad®, Android™ phone or Android tablet

This entry was posted on April 22, 2013 at 4:49 PM and has received 823 views. There are currently 0 comments. Print this entry.

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 entry was posted on March 25, 2009 at 8:54 PM and has received 2166 views. There are currently 1 comments. Print this entry.

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 entry was posted on April 16, 2008 at 4:57 PM and has received 2341 views. There are currently 0 comments. Print this entry.

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 entry was posted on March 16, 2008 at 5:26 PM and has received 2182 views. There are currently 0 comments. Print this entry.

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 entry was posted on February 17, 2008 at 12:52 PM and has received 3089 views. There are currently 0 comments. Print this entry.

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 entry was posted on January 17, 2008 at 1:10 PM and has received 1833 views. There are currently 0 comments. Print this entry.

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 entry was posted on December 17, 2007 at 1:18 PM and has received 2025 views. There are currently 0 comments. Print this entry.

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 entry was posted on November 17, 2007 at 1:23 PM and has received 1889 views. There are currently 0 comments. Print this entry.

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 entry was posted on October 17, 2007 at 1:35 PM and has received 1844 views. There are currently 0 comments. Print this entry.

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 entry was posted on September 17, 2007 at 1:48 PM and has received 1827 views. There are currently 0 comments. Print this entry.