reghakr
Essential Member
Recognize the worst traits of programmers everywhere and save yourself from developer hell
Being a good developer takes a lifetime of training and practice. But without proper discipline, even the best programmers risk falling prey to their worse natures. Some bad habits are so insidious that they crop up again and again, even among the most experienced developers. I speak of nothing less than the seven deadly sins of software development. Read on to hear how lust, gluttony, greed, sloth, wrath, envy, and pride may be undermining your latest programming project as we speak.
First deadly sin of software development: Lust (overengineering)
Modern programming languages tend to add features as they mature. They pile on layer after layer of abstraction, with new keywords and structures designed to aid code readability and reusability -- provided you take the time to learn how to use them properly.
At the same time, the discipline of programming has changed over the years. Today you have giant tomes of design patterns to pore over, and every few months someone comes up with a new development methodology that they swear will transform you into a god among programmers.
But what looks good on paper doesn't always work in practice, and just because you can do something doesn't mean you should. As programming guru Joel Spolsky puts it, "Shipping is a feature. A really important feature. Your product must have it."
Programmers who fetishize their tools inevitably lose sight of this, and even the seemingly simplest of projects can end up mired in development hell. Resist your baser impulses and stick to what works.
Second deadly sin of software development: Gluttony (failing to refactor)
Nothing is more gratifying than shipping software. Once you have a working product out in the wild, the temptation is strong to begin planning the next iteration. What new features should it have? What didn't we have time to implement the first go-round?
It's easy to forget that code seldom leaves the door in perfect shape. Then, as features accumulate with successive rounds of development, programmers tend to compound mistakes of the past, resulting in a bloated, fragile code base that's too tangled to maintain effectively.
Instead of gobbling up plate after plate of new features, restrain yourself. Evaluate your existing code for quality and maintainability. Make code refactoring a line item on your budget for each new round of development. Clients may see only the new features in each release, but over the long term, they'll thank you for keeping off the fat.
Third deadly sin of software development: Greed (competing across teams)
The excessive desire for wealth and power -- how else to explain the motives of programmers who compete with their own coworkers? It starts when other teams are left off email lists, then proceeds to closed-door meetings. Next thing you know, one team has written a library that reimplements more than half of the functionality already coded by another team.
Programming teams seldom reinvent the wheel out of malice, but lacking clearly defined objectives, they can easily latch onto responsibilities much broader than are strictly necessary. The result is a redundant, unmanageable code base, to say nothing of the budget lost to duplicated efforts. One of the top priorities of managing a development project should be to make sure each hand knows what the other is doing, and that all the teams are working toward a common goal. Share and share alike should be your motto.
Fourth deadly sin of software development: Sloth (not validating inputs)
The list of basic programming mistakes is long, but the sin of failing to validate input is so pernicious that it bears special consideration. Why this seemingly amateur error still crops up in code written by experienced programmers is baffling. And yet, many commonplace security vulnerabilities, from buffer overruns to SQL injection attacks, can be traced directly to code that operates on user input without validating it for correct formatting.
Modern programming languages provide many tools to help coders keep this from happening, but they have to be used properly. Remember, a Web form that uses JavaScript to validate its inputs can be easily sidestepped by disabling JavaScript in the browser or not using a browser to access it at all. Input validation should be baked into the core of your application, not sprinkled onto the UI. Anything less is simple laziness.
Fifth deadly sin of software development: Wrath (not commenting code)
What act could be more hostile to your fellow programmers than failing to comment your code? I know, I know: Well-written code is its own best documentation. Well, guess what? Those methods you wrote at two in the morning last Thursday weren't exactly well-written code. (And if you're a Link Removed due to 404 Error hacker, you owe me nine Hail Marys.)
It's easy for programmers to forget that the code they write today may live on long after they've left the job. To the programmers who replace them falls the unenviable task of figuring out what each snippet of code actually means. So have mercy, and leave them a few hints.
But remember, unintelligible comments or commenting too much can be as bad as not commenting at all. Comments like "this is broken" or "don't touch this ever" aren't much help to anybody. Neither are redundant comments explaining simple operations, such as variable initializations. Code is its own best documentation of what it does; comments should be there to explain the why.
Sixth deadly sin of software development: Envy (not using version control)
It's hard to believe there are still software projects in 2011 that exist as a directory tree on a file server, jealously guarded by one "master maintainer." Scattered around the office are duplicates of this tree on individual developers' workstations, each slightly different -- though no one knows exactly how.
Maybe you have reasons for not implementing version control on your projects. Maybe it started small and just got out of hand. But powerful, Link Removed - Invalid URL are readily available today for free. Service providers are even available to host code for distributed projects for minimal cost. There is no reason why you shouldn't make starting a code repository one of the first steps in any project, even small ones -- unless, that is, you can't stand to see anyone commit code changes but yourself.
Seventh deadly sin of software development: Pride (not unit testing)
It's often tempting to pat yourself on the back for a programming job well done. But how do you know it's well done? What are your metrics?
Unless you've validated your code against specific test cases, you have no idea whether it works as advertised and is completely free of defects. But all too many developers fail to produce unit tests for their code. They claim time spent testing is time not spent implementing features. In fact, some developers fail to even write QA testing into their project budgets.
What can I say, except that pride goeth before a fall? By the time defective code arrives in the client's hands, it's too late to undo the mistake. The more you plan for unit testing before your code ships, the more damage control you can avoid later.
Source: http://www.infoworld.com/d/developer-world/the-7-deadly-sins-software-development-872?page=0,1&source=rss_infoworld_top_stories_
Being a good developer takes a lifetime of training and practice. But without proper discipline, even the best programmers risk falling prey to their worse natures. Some bad habits are so insidious that they crop up again and again, even among the most experienced developers. I speak of nothing less than the seven deadly sins of software development. Read on to hear how lust, gluttony, greed, sloth, wrath, envy, and pride may be undermining your latest programming project as we speak.
First deadly sin of software development: Lust (overengineering)
Modern programming languages tend to add features as they mature. They pile on layer after layer of abstraction, with new keywords and structures designed to aid code readability and reusability -- provided you take the time to learn how to use them properly.
At the same time, the discipline of programming has changed over the years. Today you have giant tomes of design patterns to pore over, and every few months someone comes up with a new development methodology that they swear will transform you into a god among programmers.
But what looks good on paper doesn't always work in practice, and just because you can do something doesn't mean you should. As programming guru Joel Spolsky puts it, "Shipping is a feature. A really important feature. Your product must have it."
Programmers who fetishize their tools inevitably lose sight of this, and even the seemingly simplest of projects can end up mired in development hell. Resist your baser impulses and stick to what works.
Second deadly sin of software development: Gluttony (failing to refactor)
Nothing is more gratifying than shipping software. Once you have a working product out in the wild, the temptation is strong to begin planning the next iteration. What new features should it have? What didn't we have time to implement the first go-round?
It's easy to forget that code seldom leaves the door in perfect shape. Then, as features accumulate with successive rounds of development, programmers tend to compound mistakes of the past, resulting in a bloated, fragile code base that's too tangled to maintain effectively.
Instead of gobbling up plate after plate of new features, restrain yourself. Evaluate your existing code for quality and maintainability. Make code refactoring a line item on your budget for each new round of development. Clients may see only the new features in each release, but over the long term, they'll thank you for keeping off the fat.
Third deadly sin of software development: Greed (competing across teams)
The excessive desire for wealth and power -- how else to explain the motives of programmers who compete with their own coworkers? It starts when other teams are left off email lists, then proceeds to closed-door meetings. Next thing you know, one team has written a library that reimplements more than half of the functionality already coded by another team.
Programming teams seldom reinvent the wheel out of malice, but lacking clearly defined objectives, they can easily latch onto responsibilities much broader than are strictly necessary. The result is a redundant, unmanageable code base, to say nothing of the budget lost to duplicated efforts. One of the top priorities of managing a development project should be to make sure each hand knows what the other is doing, and that all the teams are working toward a common goal. Share and share alike should be your motto.
Fourth deadly sin of software development: Sloth (not validating inputs)
The list of basic programming mistakes is long, but the sin of failing to validate input is so pernicious that it bears special consideration. Why this seemingly amateur error still crops up in code written by experienced programmers is baffling. And yet, many commonplace security vulnerabilities, from buffer overruns to SQL injection attacks, can be traced directly to code that operates on user input without validating it for correct formatting.
Modern programming languages provide many tools to help coders keep this from happening, but they have to be used properly. Remember, a Web form that uses JavaScript to validate its inputs can be easily sidestepped by disabling JavaScript in the browser or not using a browser to access it at all. Input validation should be baked into the core of your application, not sprinkled onto the UI. Anything less is simple laziness.
Fifth deadly sin of software development: Wrath (not commenting code)
What act could be more hostile to your fellow programmers than failing to comment your code? I know, I know: Well-written code is its own best documentation. Well, guess what? Those methods you wrote at two in the morning last Thursday weren't exactly well-written code. (And if you're a Link Removed due to 404 Error hacker, you owe me nine Hail Marys.)
It's easy for programmers to forget that the code they write today may live on long after they've left the job. To the programmers who replace them falls the unenviable task of figuring out what each snippet of code actually means. So have mercy, and leave them a few hints.
But remember, unintelligible comments or commenting too much can be as bad as not commenting at all. Comments like "this is broken" or "don't touch this ever" aren't much help to anybody. Neither are redundant comments explaining simple operations, such as variable initializations. Code is its own best documentation of what it does; comments should be there to explain the why.
Sixth deadly sin of software development: Envy (not using version control)
It's hard to believe there are still software projects in 2011 that exist as a directory tree on a file server, jealously guarded by one "master maintainer." Scattered around the office are duplicates of this tree on individual developers' workstations, each slightly different -- though no one knows exactly how.
Maybe you have reasons for not implementing version control on your projects. Maybe it started small and just got out of hand. But powerful, Link Removed - Invalid URL are readily available today for free. Service providers are even available to host code for distributed projects for minimal cost. There is no reason why you shouldn't make starting a code repository one of the first steps in any project, even small ones -- unless, that is, you can't stand to see anyone commit code changes but yourself.
Seventh deadly sin of software development: Pride (not unit testing)
It's often tempting to pat yourself on the back for a programming job well done. But how do you know it's well done? What are your metrics?
Unless you've validated your code against specific test cases, you have no idea whether it works as advertised and is completely free of defects. But all too many developers fail to produce unit tests for their code. They claim time spent testing is time not spent implementing features. In fact, some developers fail to even write QA testing into their project budgets.
What can I say, except that pride goeth before a fall? By the time defective code arrives in the client's hands, it's too late to undo the mistake. The more you plan for unit testing before your code ships, the more damage control you can avoid later.
Source: http://www.infoworld.com/d/developer-world/the-7-deadly-sins-software-development-872?page=0,1&source=rss_infoworld_top_stories_
