Software,Companies,Don,Sabotag computer Software Companies, Dont Sabotage Your Long-Term Success!
----------------------------------------------------------Permission is granted for the below article to forward,reprint, distribute, use for ezine, newsletter, website,offer as free bonus or part of a product for sale as longas no changes a Gone are those times when the companies and the organisations didn't need a hi-tech system to handle them. Owing to the considerable increase in the business sector and thus, an enormous increase in the complexity of the organisational struc
Over the years, Ive paid a lot of attention to how companies recruit computer programmers. During that time, Ive noticed how managers frequently make hiring decisions that seem to make sense in the short term, but which result in long-term chaos. Ive seen the kind of havoc that this can wreak, and how devastating it can be to the companys future.Id like to say a few words about that today.The companies that Ive observed typically pay attention matters such as industry backgrounds, years of experience, and so forth. They want to know what types of projects the applicants have worked on, which compilers and operating systems theyre familiar with, which communication protocols and software packages theyve used, and so forth. Many also want to know about the employees work ethic and personality, but in the end, the hiring decisions frequently boil down to the employees work experience and how much training that person would require.All of those are important, sensible considerations. As I observed these companies though, I noticed that most of themabout 80% or morepaid little or no attention to whether the applicant had a clean, readable programming style. They were deeply concerned about whether the applicant could get the job done, and didnt seem to care much about whether their software could be easily understood and modified by others, years down the road.To some extent, this is understandable. After all, the immediate goal of most companies is to develop working products that they can sell. What many forget, however, is that they are supposed to be marathoners, not sprinters. They need to think more in terms of finishing the entire race, and less in terms of achieving short-term victories.It also betrays a certain naivete about the immediate damage that can result from poor programming style. After all, even the best software is rarely bug-free. A programmer who writes clean, legible software will be able to debug his own work more reliably than someone who writes patchwork code. The latter may arguably provide fixes more quickly (and even thats debatable!), but the results will be unreliableand when time is short, thats a luxury which companies cannot afford.Employers should also remember that good programming style is not something thats easily taught. Any competent programmer can learn the mechanics of language syntax and function calls; however, someone who understands little about the artistry of structured programming or proper object orientation is unlikely to master these things on the job. Ive seen this happen (or rather, fail to happen) time and again. This, despite the abundance of books and journals which discuss this matter at great length.I also think that companies should pay greater attention to the prospective employees technical writing skills; after all, external documentation (e.g. user manuals, design documentation) can be critical to the softwares maintainability. Besides, in my experience, programmers who write well in English are more likely to write software too. And why not? Programming languages are ultimately just thatlanguages. Someone who can express himself well in English is more likely to communicate clearly and effectively in his source code as well.For these reasons, I urge any company thats hiring a programmer to ask incisive questions about an applicants coding style. How does he name his variables? How many lines of code should a function occupy? Does he use global variables, and if so, when? What kinds of books has he read on programming style? Ideally, companies should also ask for samples of an applicants source code and technical documentation, to verify that these lessons are put into practice. This takes a little extra effort, but it can help a company avoid sacrificing long-term success for the sake of dubious short-term gains.
Software,Companies,Don,Sabotag