XtractPro - Data Extraction and Transformation

	One of my main areas of expertise I specialized on the last couple of years is fixing or getting done in a short laps of time software development projects left undocumented or messed up by former employees or contractors. Here are guidelines on how to handle both the technical aspects and the company policies when you are brought in to handle such projects.

How to Recognize 911 Software Development Projects

1. They need you "yesterday". Project started years ago, but they want you to get it done now in only a few months or weeks.
2. Serious lack of project-related documentation. Or tones of obsolete, inconsistent, unuseful documents and paperwork.
3. Requirements not properly translated into formal statements, as a solid foundation for the architecture and design.
4. Existing code not documented, not well organized and not properly structured. Lots of experimental code and prototyping spread all over the place, using technologies and techniques obsolete today.
5. Company running out of money. Existing funding has been spent on "best practices", meetings, expenses to bring people on board and later fire them.
6. Former developers "owned" the code and took a customary "job protection" approach, to make themselves irreplaceable. They kept the code undocumented and added unnecessary complexity. Once they left, it was hard to find someone else to dig into their mess.
7. Programmers treated poorly, with disrespect. Lack of motivation, for different reasons, related or not to the project itself.
8. People hired with no adequate "know how" and appropriate skills. Interns or beginner programmers hired and trained for the required technologies, but with no real-life project development experience.
9. Underestimated learning curve of people assigned on the project. Underestimation of time and effort for implementation and design, or the usage of third-party components for the project.
10. People spend more time in meetings than actual design and development. Team members who don't know to get into effective and useful roles, and become more vocal than prolific.
11. Visible micromanagement. Agile development approach, but with roles poorly determined or respected. Poor team work and communication, even if chances are you'll hear these words very often.
12. Too many Chiefs, not enough Indians.

How to Deal with 911 Software Development Projects

1. Be realistic and honest to yourself. Get in only if you have the required technical skills and you can handle the pressure of time and budget constraints.
2. Never accept such an assignment if you are not satisfied from start with your hourly rate. While you can eventually adapt in time to unexpected company politics and attitudes, you have to remain happy you are rewarded properly for your efforts.
3. Get "hands on" and recognize which technical bottlenecks to address first. This could be the user requirements, the overall architecture or the code itself.
4. Try to prove from start, in a pragmatic way, you are not "just another programmer". Ask the right questions, self-organize your work, establish an efficient communication procedure, come up quickly with some effective and positive results.
5. It is expected some people will try to over-control and micromanage you. Don't get frustrated, it might be just because they do not know you yet and want to make sure you'll bring expected results.
6. Try to get your client - managers and supervisors - in an effective supporting role, rather than over-controlling. External intervention is not always for the best of the project, but people who hire you always feel entitled to get into whatever you are doing. If that's the case, try to get more independence in time, after you start producing. Your client should become more confortable you don't need such close supervision to do your work.
7. Be very professional, use diplomacy and self-control. External temporary contractors are still frequently treated in a poor way, but don't take this personal. If the attitude persists, try to get some distance by asking to work eventually from home and stick strictly to the tasks you've been assigned to.
8. You've been just temporarily hired to accomplish a specific project development task and nothing more. You shouldn't care or stick your nose into any of company's problems, you are not there for that.
9. Determine realistic milestones and get them done, with frequent deliveries. Keep everyone in touch with what you're doing every 2-3 days. Show them proven and functional results.
10. Learn how to handle pressure. Remain calm and always look for solutions, not pointed fingers.
11. It doesn't matter how good you are on a technology and how many years of expertise you have on your back, there will be cases where you will experience slowdowns, due to hard-to-find bugs on third-party components, the infrastructure or even your own work. When this happens, take your time to calmly inform your supervisors about the problem and how you are looking for a fix.
12. Figure out from start what are the actual time constraints and the budget left for the project. It is not always what you are told at the beginning. Most managers expect delays and take safety precautions pushing for more, just to make sure they will get the project done later in time. However, some deadlines could be what they are, this means the project should be delivered not later than at the end of month X, in which case you have to make sure at least some budget is eventually available for unexpected overtime.
13. If the time and budget constraints are high, and there is not enough time to deal properly with all project development phases - such as best design, proper specifications and enough time for testing - propose from start a "quick and dirty" approach. This means you'll still do your best to get the project implemented in time with the required functionality, but you make your client aware bugs may latter show up and may need additional funding. It is not rare that actual beneficiaries of a project want to see first an implementation, and they become flexible to invest more for fixes once they see you are producing and are on the right track.
14. Simplify. Get rid of complex design solutions and coding techniques, if they are not required and really necessary for the project. Many teams adopt first a very complex approach, just to figure out later that this implies more time spent on debugging, maintenance and keeping up-to-date technical specifications.
15. Be very careful with system architectural decisions, because they are hard to reconsider and change later on, once coding started.

Subscribe and Share:

Leave a Reply