You have a close decision to make on hiring a software developer or several different ways to architect a program.
If one sucked and the other was brilliant it would be easy (pick the brilliant one!)
But often there are two or more options that are really close and it is hard to decide which is best. And the ramifications of a bad decision could be thousands of dollars of extra cost, a failed project and wasted days of work...
How to decide?
Some common ways are
The pros and cons list. List out the benefits and drawbacks of each choice. Pick the one with most benefits and least drawbacks
Weighted pros and cons. Same as previous method but give each aspect of the choice a weight depending on how important it is. Pros get a number +1 to +10 and cons a number -1 to -10, depending on how good or bad they are. Multiply the score by the weight and add them up. Pick the option with the best score. eg in hiring you might have one aspect of the choice is database design with weight 3. Candidate A is a +5. Candidate B is -2. So the contribution for for A is 3 x 5 = 15 and for B is 3 x (-2) = -6. Add these to the weighted scores for all other aspects of your decision to get the total scores.
I have used your weighted scoring system successfully too. Hey I was a mathematician by training at college! :-)
I give extra weight to a decision is easily reversible/gives early feedback on whether it is the right course/can be course corrected down the road.
Particular areas I have found this useful for are:
Scoring job candidates on the different skills and characteristics in the job req
Scoring clients by idealness (ie easy to work with, have budget for our kind of task, communicate clearly, appreciate quality software development etc) and then "firing" the bottom 10% each year.
Scoring prospects the same kind of way and focusing my energy on the top scorers.
Flip a coin. If the choices are really nearly equal it doesn't matter. Pick one at random. Then see how you feel about the decision. If you feel good, great go with it. If you get a bad feeling in your stomach the it is not a good choice, pick the other one! (You just realized new information about the first choice).
Test them out with a trial. Perhaps you can hire there different candidates for a few hours of paid work to see how you get on and what they really can do. Or if you have different program designs you can hack out the essence part of the algorithm (with no UI) and throw together some realistic volume of test data and compare speed (or does the algorithm even work at all!).
All the above methods are pretty common in management and software development. Here are two further thoughts on close decisions:
1. The time value of decisions. The values of the different options are usually not fixed over time. Often they decline over time.In addition the days and energy you spend making a decision are time and energy you could have spent on other productive tasks in your business, so they have a cost too.
For example in hiring, the slower you are at responding to the different candidates the less enthusiastic they are about the job, and the more likely they are to pick another company. Plus the more time you have lost to other money making tasks.
Suppose you have two candidates A and B with values of 51 and 49 on Day 1 and that they loose 3 points each day you wait/it costs 3 points in your energy used each day.
Here are the values of the options over time:
In this case making a fast "bad" decision on Day 1 by hiring B at 49 points is actually better than the slow "correct" decision of hiring A on Day 3 at 45 points.
True sometimes the value of the choices might not change over time but the cost of continuing to spend your time/energy on the decision day after day definitely applies. Time that could have been spent making money for your business other ways. So there is still a time value to a decision.
The only way to avoid that is to not worry about the decision or spend any time on it at all until you next consider the choice. A deliberately delayed decision. I have seen entrepreneurs successfully do this when they realize that they are too busy/lack resources to implement yet another change this year and "consciously decide not to decide" until next January.
I also did not include the lost opportunity cost of a delayed decision. All the profits/new deals you could have made in the days (weeks?) spent decision making using either choice A or B.
We are not just comparing choice A to B. But also to choice N - do nothing. In the case of a 49/51 near equal decision I imagine the value of N is much less than either A or B.
In sales often clients don't take the cost of choice N into account because they have had the problem and been in this choice for so long. It is my job wearing my salesperson hat to help them see the true costs of choice N, as well as the costs and benefits of choosing buying from me. Bringing more consciousness to their buying decision.
2. Intuitive decision making. When a decision is pretty equal and complex then using intuition processes all the complexity at a subconscious level, saving my conscious processing power for other thoughts. It is also fast to do.
This is one method for making intuitive decisions, or at least giving you extra info for your conscious decision process.
Heart based decision process (example for picking from 4 choices)
Drop down into your heart (imagine your consciousness is in an elevator from your head).
Hold each of options 1 - 4 in your hand one at a time.
Bring your hand to your heart and notice what you feel.
Then bring option 5) Something else (that I don't consciously know right now) to your heart too.
Pick the option that makes your heart feel most open and happy.
Notice any extra info you get on each option eg heart feels heavy, a color or sound that appear, other body sensations, new inspired thoughts that come to you
If you get the "Something else" option then be ok to be patient a few days and see what occurs to you or synchronisities that occur that point to what it is.
If you don't get users involved early in the project, you risk ending up with shelfware. That means that you wrote some great code, 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
Having a project champion
Early user buy-in
Early usability testing
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
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.
This entry was posted on October 28, 2013 at 4:34 AM and has received 1186 views. There are currently 0 comments.
Print this entry.
Your 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.
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.
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.
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.
This entry was posted on September 4, 2013 at 4:18 PM and has received 2309 views. There are currently 0 comments.
Print this entry.
Have 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:
Clear written requirements
Requirements sign off
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.
This entry was posted on August 20, 2013 at 12:18 PM and has received 1819 views. There are currently 0 comments.
Print this entry.
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
Lack of user and executive management support
Poor planning and milestones
No vision and objectives
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!
Required: Windows® 7, Vista, XP or 2003 Server
Required: Mac OS® X 10.5 or newer
Required: iPhone®, iPad®, Android™ phone or Android tablet
This entry was posted on April 22, 2013 at 2:49 PM and has received 2583 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 210 days at home!
This entry was posted on March 25, 2009 at 6:54 PM and has received 2538 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.
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 2:57 PM and has received 2673 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 3:26 PM and has received 2508 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 10:52 AM and has received 3528 views. There are currently 0 comments.
Print this entry.