Contact Us Today!   |   + 1 (301) 424 3903



Do they think you are are a super human developer?

Have you been in this meeting?

The big boss pressures the PM to pressure you to say that you can code anything.

After all you are the expert right?

They believe that developers can do anything, even the most ridiculous tasks. Of course, developers always do; they can do anything.

They will ask you to build a rocket ship with pebble stones. They will give suggestions on how to do it, and they often end up confusing you and embarrassing themselves as well.

Developers need to be left alone with the how's. You can, build a rocket ship, yes -- maybe not with a pebble, but you'll get your rocket ship in the end.

Just listen to your developers when they point out the impossible like the "green" red lines...

 

4 ways to prevent code death by shelfware

What is Shelfware?

If you don't get users involved early in the project, you risk ending up with shelfware. That means that you wrote some great Shelfwarecode, the operation was a success but the patient died on the table. None of the users want to use the application and it's left on the shelf.  What can you do about this? 

Some of the keys to successful projects are getting

  • Executive support
  • Having a project champion
  • Early user buy-in
  • Early usability testing

Executive support

The most important success factor for a software project is to have executive and user support for the project. Why is that an issue on a project?  Because if you're working on a project and you can't get decisions made, or they get made at the end of the project after you've already coded your application in a totally different way, then that will screw up your deadline. Also expect cost overruns and in the worst case total project failure and cancellation!

Another issue I've seen is where two departments have some kind of argument over whether you're going to get data or not, and no one higher up will bang their heads together to get the issue resolved.

Having an executive user to motivate the troops, use a stick when necessary and to break ties is vital to any successful project

Project champion

A project champion is not formally on the project team but they're there to support it.  They might be an executive or perhaps a power user. Either way they are passionate about the project. They promote the project vision within the organization, provide useful assistance if anything has to get dealt with on a political level and may also provide early use cases for the application.

User change motivation

People don't like to change and that includes users.  Users don't like change:  they don't like new processes and they don't like new software.  You've got to use some kind of psychology or motivation as to why they would want to change, why do they want to use this new version of this app and what's in it for them.  If you can answer the “what's in it for them”, they're far more likely to want to use the application.

Early usability testing

Involve users in the early stage of a project by doing prototyping and user interface reviews to get their feedback.  Some people even go as far as videoing people using the prototype to see where they get confused or see how many clicks they do to complete key operations; and then altering the application to make it easier to use. 

At a later stage do some kind of A/B test where you have two versions of a key page and then see how people respond to each one and what the click through rates are. Then adjust the page layout and functionality to improve the user experience or actions.

How buggy is your peopleware?

PeoplewareYour hardware is well tuned. Your software uses the latest techniques. But your projects still fail. Why? It probably is buggy peopleware. Peopleware are the political, culture and social issues in software development - which often gets a back seat to technical issues. Peopleware problems often are the key to why projects fail. 

Team dynamics

Do you have low developer productivity on your team where not much good quality code gets written?  It may be poor teamwork where people aren't working well together, or even actively disrupting the project.  I've seen projects where it seems someone from the project is purely there to cause trouble.  Then there is bad group dynamics where just things just don't jell and you can't get the data that you want from the users that are involved or other things of that nature.

Peopleware issues have been studied for about 15 or 20 years but they are not so widely known.  Just in case you’ve never heard of the book Peopleware by Tom DeMarco and Timothy Lister then highly recommend checking out.  It is required reading on many Microsoft software development teams.

Hire smart

One of the first things is make sure you hire smart people for your team.  Personally I look beyond resumes and interviews and give candidates a practical programming test to do. Unfortunately I have found in my over 35 years of software development experience that some poor programmers are great at BS. But seeing the results of what a developer actually codes will show efficient coding ability, communication skills and the maintainability of their code. And can not be faked.

Having hired smart people, trust them and don't micro manage them. Trust them to make the right decisions on the project given the written vision, requirements and parameters for it. 

Office space and interruptions

Do your developers have a private office with a window? The privacy is helpful because programming takes a lot of thinking and often, if you're working on a complex piece of code, it takes 15 or 20 minutes to really get into the flow of writing that code.  Then, if you get interrupted, it takes another 15 minutes to get back into the flow after the interruption has gone away. So a private office helps you keeping the interruptions down.  If you're in the middle of a coding spree then turn your phone to go to voice mail without ringing and turn off email notifications too.

What is a good boss for software developers?

A good peopleware manager will protect your developers from senior executives or corporate politics that might get in the way of you getting productive work done, rather than interfering and micromanaging with what you're doing.  Dilbert’s Pointy Haired Boss need not apply for the job.

Company policies affect software quality

Company policies can either support good code of they can totally get in the way of doing it.  Having someone higher up in the organization to protect the programming and project team from people that interfere can be very helpful.

Peopleware survey results

I did a survey of developers and software development managers during a recent webinar with the following results:                      

  • No private office with door and windows 55%
  • Too many interruptions to get into programming flow 68%
  • Corporate politics 45%,
  • Bad hiring practices 18%
  • Other peopleware issues 14%

Nearly two thirds of people get too many interruptions to get stuff done.  That explains why so many people do a lot of their work by coming into the office early, working from home or staying late after hours when the number of interruptions goes down. 

There are all workarounds for this issue, but really, if you can set up the environment where you don't get interruptions in the first place, that would be better.  Really, in ColdFusion projects, it's not how many hours you put in, it's how much good code you get written.  And the environment affects that a lot. 

Summary

In my lifetime as a programmer and project manager, I have experienced many different peopleware situations. I can tell you from experience that improving your peopleware directly improves software quality and project goal attainment. For example after we worked to reduce programmer interruptions and office noise we saw code quality increase. Improving our hiring practices ten years ago led to great programmer productivity and happier clients.

3 keys to Avoiding Scope Creep

Scope creeo redoHave you been on a project with scope creep recently? The scope increases, that leads to late delivery of the project, budget overruns, stress, late nights spent coding when you’d rather be doing other things.  Plus all those endless changes have made to the code base decline in quality from all the work done under pressure.  Writing code is a very brain-intensive task and when people are stressed out, their code quality tends to go down.

In a recent survey of attendees of a webinar I gave on “7 ways ColdFusion projects fail” 89% of people listed scope creep as a problem they have.

Here are three keys to avoiding scope creep problems:

  1. Clear written requirements
  2. Requirements sign off
  3. Change management system

1. Clear written requirements

So how does scope creep on a project?  You start off with one set of requirements and then you discover other ones as you're writing the code.  This is not surprising as users find it difficult to express their needs in a way that developers can understand.

What can we do about these problems and other requirements issues?  I think one of the most important things is having clear written requirements.  That's not just writing.  It's also screen shots or mockups of any screens and reports that you have in the system ­- because users often can't fully understand a written set of requirements but when they see a picture of something they can give you precise feedback that this is or isn’t something they want.

2. Requirements sign off

Next, it is important that an executive on the client side signs off these requirements and agrees that we're going to stick with this functionality until we deliver version 1.0 of the app.  I recommend printing your requirements out (do screen prints if you have prototype screens) and literally have an executive sign the paper. While this is more work than getting a verbal go ahead, I have found that each person remembers the terms of verbal contracts differently… Physically signing gets people to read what they are signing, provides a written record of the scope and makes everyone take the process seriously.

3. Change management system

If there are any changes that come up, have some kind of way of tracking them in a formal change request system.  A spreadsheet is the simplest option.  A change tracking system that you buy or make yourself might be more robust. The important point is that you track the changes and you evaluate each one.  “Okay, are we going to do these in the next version or are we going to adjust our schedule to get them done in this version with a later delivery date?”

In my lifetime as a programmer and project manager, I have seen a vast amount of scope change. I can tell you from experience that having and using a change management system is definitely one of the elements needed to avoid scope creep.

At TeraTech, our promise is to deliver projects on time and on budget. Some of the reasons that we can promise what we do is because in addition to other processes, we insist on very well defined requirements with executive sign-off. Once in project mode, we are diligent about using a change management system to keep on track.

7 ways ColdFusion projects fail - webinar Wed 5/1/13 1pm EDT

Headaches from failing ColdFusion projects?

  • 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
We will also look at your questions and problems during the Q&A.

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

10 tips to recession proof your development career

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 210 days at home!

TeraTech Development Approach - Web Services and Testing

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.

TeraTech Development Approach - Design in Fusebox and Database Access Components

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.

TeraTech Development Approach - Web Form Prototype

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.

TeraTech Development Approach - Database Review

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

More Entries

BlogCFC was created by Raymond Camden. This blog is running version 5.9.8.012. Contact Blog Owner