Language communities and best practices
-
Do this long enough and you will come to intimately realize why most of that is utter crap. Most 'best practices' are ways of herding large groups of substandard programmers in a software factory all the while thoroughly killing the productivity of the truly talented who know when to apply those rules and most importantly when not to. I fully understand why they are necessary in a factory setting with cheap labour and it pays to understand them and their philosophy but it reduces the fine art of software development to the level of any production line worker. A good developer, a truly talented and motivated and experienced one, can outperform any number of factory programmers following the ritual of their best practices religion. I say any number because as you add more factory programmers to a problem you get exponentially decreasing productivity.
Hockey wrote:
Anyways, my question is,
? And your question was??? ;)
When everyone is a hero no one is a hero.
John C wrote:
A good developer, a truly talented and motivated and experienced one, can outperform any number of factory programmers
According to Jeff Sutherland (credited with creating Scrum), IBM once published a study that found that using a "surgical team" was the most productive way they (IBM) had found to develop software. As the name implies, this team consists of a "surgeon", a single, highly talented individual who holds the design & architecture in their head & does most of the coding, surrounded & supported by helpers. Scrum was developed as an attempt to match this level of productivity in an environment without surgeons (i.e. no highly talented individuals). If you have highly talented individuals (selecting the "surgeon" based on skills specific to the project at hand, or even to cross skill an up & comer), it would seem that best practice is just to let them get on with it in the way they work best (i.e. there is no single best practice). Anything else is just handicapping your team, not helping. If you don't have highly talented individuals, then you've got ask yourself "why don't I have any highly talented individuals"?
T-Mac-Oz
-
Hockey wrote:
I'm finding the only constant in software development is change it self.
Precisely point #1. Point #2 is that there is a glut of techniques, approaches, best practices, and so forth (even the waterfall method of developing an application has its good points) and a dearth in intelligent people that know how to pick and choose the best from all of these methodologies, and a dearth of management that is willing to support what these methodologies really cost. In a nutshell, there's lots of wisdom and little common sense. I was just discussing with my gf, not 10 minutes ago, how there isn't a single company I've ever worked for or contracted for that puts testing in the forefront of budget and time allocations. Where is the company that says "before one line of code is written, we are going to invest in equipment, tools, people and training to develop a solid QA dept"? If there are such companies out there, I haven't heard about them. And that's just one example. Obviously, testing isn't the only priority. If your product doesn't have an architecture that is flexible enough to handle new technologies and new competition, then you're going to lose marketshare as well. If you don't invest in documentation and tech support, you're going to lose marketshare. And so forth. Frankly, all these methodologies are meaningless in the face of the wrong (or even lack of) decisions that are made up front, before any product is ever designed or a line of code is written. And they tend to be meaningless in light of the course corrections made during development as well, that usually never retain the original guidance. Marc
Marc Clifton wrote:
Where is the company that says "before one line of code is written, we are going to invest in equipment, tools, people and training to develop a solid QA dept"?
15 years ago, my company had a large QA department. The guy who headed it was sharp, and not afraid of going head-to-head with Engineering or Marketing. Under his direction, we had formal test plans that had to be successfully completed before a product could be released to customers. That was the good part. Unfortunately, the head guy was the only guy in QA competent to pound sand. The rest of his people ranged from rigid plodders to incompetent egomaniacs. Here's an example: On one of my products, my QA 'engineer' completely restarted testing every time I released a new version of software. He never read my change lists, nor incorporated them into an adaptive test plan. The other thing he would do is never remove an issue from a bug list, even if he had verified it was corrected, until it had been shipped to customers and verified at the customer site. Since shipping authorization required sign-off on all entries in the bug list, this made things complicated. It took forever to get a new release out. In the time since then, QA has been reduced to a testing group. The guy who was the head retired. The senior group members are still plodding egomaniacs. Their test plans are a joke, and the tests themselves are formalities. Interestingly enough, our development group has 'adopted' a couple of the younger testers. They come to us directly when testing, rather than always throwing issues 'over the wall'. We get far better results out of these relationships than we ever do the formal testing process.
Software Zen:
delete this; -
John C wrote:
A good developer, a truly talented and motivated and experienced one, can outperform any number of factory programmers
According to Jeff Sutherland (credited with creating Scrum), IBM once published a study that found that using a "surgical team" was the most productive way they (IBM) had found to develop software. As the name implies, this team consists of a "surgeon", a single, highly talented individual who holds the design & architecture in their head & does most of the coding, surrounded & supported by helpers. Scrum was developed as an attempt to match this level of productivity in an environment without surgeons (i.e. no highly talented individuals). If you have highly talented individuals (selecting the "surgeon" based on skills specific to the project at hand, or even to cross skill an up & comer), it would seem that best practice is just to let them get on with it in the way they work best (i.e. there is no single best practice). Anything else is just handicapping your team, not helping. If you don't have highly talented individuals, then you've got ask yourself "why don't I have any highly talented individuals"?
T-Mac-Oz
Even better is the approach my company uses: A team of elite surgeons with overlapping specialties. For example, I primarily do user interfaces, but can step to the side to work on process control when required. The other guys can work on UI when needed. Occasionally a specialist will step in and tidy things up after the fact if required. We don't have any junior developers, since our product field doesn't lend itself to turn-the-crank programming. Our small group of products incorporate custom hardware in a performance-critical application. These products are maintained and enhanced over a long period of time. It takes us six months to a year to bring a new engineer up to speed. By the time they're ready, they're no longer a junior developer.
Software Zen:
delete this; -
I develop mostly in PHP these days (the last several years actually) and one thing i have noticed about that community, is they are far more adopting of best practices that C/C++/C# at least that is the impression I have of browsing CP all these years. Design patterns do not seem to be disscussed nearly as much as I find they are in the Java community, however OO best practices like OCP, dependency injection, etc I have seen disscussed in C++ literature... It's almost like design patterns, etc are expected learned through osmosis in languages like C# - I realize that Microsoft has the MS patterns repo, but Java also has it's blueprints...but Java forums are usually a lot more buzz with design or architectural, best practice type questions... For instance, behavior driven development...I just spent the last 3-4 days studying TDD/BDD and I can honestly see BDD being the 'better overall' approach. I've already encountered a situation where thinking in terms of behavior versus classical testing has eliminated some potential ambiguity. PHP IMHO is middle ground on best practices. Like ASP.NET, it's easy to learn, so there are tons of eager developers (actually far more than ASP) ready to start hammering out code and maybe make some money (most are horribly developed with no architecture). The lack of any formal frameworks in PHP certainly has sparked some serious interest in PHP to develop a solid, reusable framework (Zend, Symphony, Cake, etc). Probalby more MVC frameworks in PHP than any other language. I wonder if because Microsoft developers (desktop, web, etc) already have all the boilerplate code generated for them, they have no interest in learning about patterns and architecture and thus the lack of interest in keeping up with best practices??? I did a quick search on CP for BDD (Behavior Driven Development) and found 5 matches... If you poke around Google, you will find that BDD is mostly centered around Ruby and perhaps Java. Is it because Java is considered some kind of academic language that the communities seem to promote best practices a little more than say C/C++/C# or even PHP for that matter? Anyways, my question is, I develop in PHP and will likely stay that way as long as PHP keeps moving forward, however I also still enjoy the CP and occasionally tinkering with ideas in C++/MFC and most recently Qt. I feel it nessecary to keep an eye on other languages such as Ruby, Java, etc...just to stay tuned in with current best practices, or at least...bleeding edge development strat
I recently attended an event where Ivar Jacobson was the keynote speaker where he stressed "practices" over process or methodology. He suggested you pick a single practice (i.e. implementing unit tests in your code or incorporating an automatic build) and implement it. Eventually over the years you will develop your own toolbox of best practices that work for you. He thought this was a more efficient and practical way to being a better developer than trying to implement a whole process like Agile, Scrum or Xtreme. It also allows you to pick and choose the individual practices that work in your particular work domain. Then as new programming processes are proposed you are free to pick and choose individual practices from the process and add them to your toolbox. It was interesting hearing this come from the man who might be considered the inventor of the software process.
-
I develop mostly in PHP these days (the last several years actually) and one thing i have noticed about that community, is they are far more adopting of best practices that C/C++/C# at least that is the impression I have of browsing CP all these years. Design patterns do not seem to be disscussed nearly as much as I find they are in the Java community, however OO best practices like OCP, dependency injection, etc I have seen disscussed in C++ literature... It's almost like design patterns, etc are expected learned through osmosis in languages like C# - I realize that Microsoft has the MS patterns repo, but Java also has it's blueprints...but Java forums are usually a lot more buzz with design or architectural, best practice type questions... For instance, behavior driven development...I just spent the last 3-4 days studying TDD/BDD and I can honestly see BDD being the 'better overall' approach. I've already encountered a situation where thinking in terms of behavior versus classical testing has eliminated some potential ambiguity. PHP IMHO is middle ground on best practices. Like ASP.NET, it's easy to learn, so there are tons of eager developers (actually far more than ASP) ready to start hammering out code and maybe make some money (most are horribly developed with no architecture). The lack of any formal frameworks in PHP certainly has sparked some serious interest in PHP to develop a solid, reusable framework (Zend, Symphony, Cake, etc). Probalby more MVC frameworks in PHP than any other language. I wonder if because Microsoft developers (desktop, web, etc) already have all the boilerplate code generated for them, they have no interest in learning about patterns and architecture and thus the lack of interest in keeping up with best practices??? I did a quick search on CP for BDD (Behavior Driven Development) and found 5 matches... If you poke around Google, you will find that BDD is mostly centered around Ruby and perhaps Java. Is it because Java is considered some kind of academic language that the communities seem to promote best practices a little more than say C/C++/C# or even PHP for that matter? Anyways, my question is, I develop in PHP and will likely stay that way as long as PHP keeps moving forward, however I also still enjoy the CP and occasionally tinkering with ideas in C++/MFC and most recently Qt. I feel it nessecary to keep an eye on other languages such as Ruby, Java, etc...just to stay tuned in with current best practices, or at least...bleeding edge development strat
It seems like the comments are focused on the initial development of the product. Not the long term maintenance of the system. These practices are designed to let mediocre developers maintenance the products. All of these methodologies come and go. Just like the glut of "new and improved" languages. As a developer it is very hard to keep up with the new and improved process developments. Unlike languages, methodologies must be learned, mentored (if at all possible), and then practiced. How many of us have that luxury? The companies are not at fault because their job is not to "test" and "beta" a new process model. They need to get products out. Our mantra here in my company is the Six Sigma thingy. Another Total Quality thingy that management can grasp and say at the dinner parties and conferences "Yeah! my company is modern too! We use xyz process in our development." As developers we try things, they may not work, so we blow them off. Companies don't have a lot of room for that type of thing. Its very costly. So does the company come up and say "Let's try this!" and then it doesn't work, which means they don't have a product. Sorry about the rambling, there is a lot to the question. I like the fact that as an industry, we're attempting to innovate, refine, and become more efficient and more transparent in what we do. Its a refreshing industry, challenging, and always evolving. What you learned five years ago may no longer be relevant. Oh, and yes, you never did ask a question to be answered, so we answered the unspoken question.
-
Marc Clifton wrote:
Where is the company that says "before one line of code is written, we are going to invest in equipment, tools, people and training to develop a solid QA dept"?
15 years ago, my company had a large QA department. The guy who headed it was sharp, and not afraid of going head-to-head with Engineering or Marketing. Under his direction, we had formal test plans that had to be successfully completed before a product could be released to customers. That was the good part. Unfortunately, the head guy was the only guy in QA competent to pound sand. The rest of his people ranged from rigid plodders to incompetent egomaniacs. Here's an example: On one of my products, my QA 'engineer' completely restarted testing every time I released a new version of software. He never read my change lists, nor incorporated them into an adaptive test plan. The other thing he would do is never remove an issue from a bug list, even if he had verified it was corrected, until it had been shipped to customers and verified at the customer site. Since shipping authorization required sign-off on all entries in the bug list, this made things complicated. It took forever to get a new release out. In the time since then, QA has been reduced to a testing group. The guy who was the head retired. The senior group members are still plodding egomaniacs. Their test plans are a joke, and the tests themselves are formalities. Interestingly enough, our development group has 'adopted' a couple of the younger testers. They come to us directly when testing, rather than always throwing issues 'over the wall'. We get far better results out of these relationships than we ever do the formal testing process.
Software Zen:
delete this;Gary R. Wheeler wrote:
We get far better results out of these relationships than we ever do the formal testing process.
If I had understood 30 years ago that nurturing relationships with people improves the entire software development process, I would, quite frankly, be in a much better place. I started, and to this day still continue to expect, that people brought together in a team will be proficient and dedicated to the tasks, and if I ask Joe to test something for me or write some code to do something, Joe will do it to the best of his abilities. And yet, time and time again, I've seen that tossing something over the fence and expecting it to be competently done does not work. But what does seem to work is building a relationship with Joe first, so that Joe is emotionally invested in doing a good job for me. Building relationships is something I'm particularly bad at, because I have strong sympathies and antipathies to people. This gets in the way of my building a relationship regardless of my personal feelings (usually negative) of others. It is quite my personal dragon. But, damnit! These relationships are so critical to actually getting work done well! And oh, irony of ironies, when I do work on relationship building, I usually find positive things to focus on and those antipathies go away! Dale Carnegie is rolling in his grave with that obvious truism, I image. If we ever meet, I'll buy you a beer for lending me your ear and the virtual couch. Thanks for letting me ramble. :) Marc
-
Gary R. Wheeler wrote:
We get far better results out of these relationships than we ever do the formal testing process.
If I had understood 30 years ago that nurturing relationships with people improves the entire software development process, I would, quite frankly, be in a much better place. I started, and to this day still continue to expect, that people brought together in a team will be proficient and dedicated to the tasks, and if I ask Joe to test something for me or write some code to do something, Joe will do it to the best of his abilities. And yet, time and time again, I've seen that tossing something over the fence and expecting it to be competently done does not work. But what does seem to work is building a relationship with Joe first, so that Joe is emotionally invested in doing a good job for me. Building relationships is something I'm particularly bad at, because I have strong sympathies and antipathies to people. This gets in the way of my building a relationship regardless of my personal feelings (usually negative) of others. It is quite my personal dragon. But, damnit! These relationships are so critical to actually getting work done well! And oh, irony of ironies, when I do work on relationship building, I usually find positive things to focus on and those antipathies go away! Dale Carnegie is rolling in his grave with that obvious truism, I image. If we ever meet, I'll buy you a beer for lending me your ear and the virtual couch. Thanks for letting me ramble. :) Marc
Trust me, I understand. This is my personal albatross as well. I expect the people around me to be as anal-retentive about the same things that I am. I get frustrated when that's not the case. Unfortunately, when I'm frustrated, the people around me know it. It has taken me years to learn to control my temper and my mouth. This attribute of my personality is one of the major reasons I will never seek a manager position. I'm just not tempermentally suited for it.
Marc Clifton wrote:
If we ever meet, I'll buy you a beer for lending me your ear and the virtual couch. Thanks for letting me ramble.
All part of the friendly service :-D. I like dark beers, BTW. The funny thing is, I think you and I would work well together until the first time we disagreed. Then, look out! :laugh:
Software Zen:
delete this; -
Trust me, I understand. This is my personal albatross as well. I expect the people around me to be as anal-retentive about the same things that I am. I get frustrated when that's not the case. Unfortunately, when I'm frustrated, the people around me know it. It has taken me years to learn to control my temper and my mouth. This attribute of my personality is one of the major reasons I will never seek a manager position. I'm just not tempermentally suited for it.
Marc Clifton wrote:
If we ever meet, I'll buy you a beer for lending me your ear and the virtual couch. Thanks for letting me ramble.
All part of the friendly service :-D. I like dark beers, BTW. The funny thing is, I think you and I would work well together until the first time we disagreed. Then, look out! :laugh:
Software Zen:
delete this;Gary R. Wheeler wrote:
It has taken me years to learn to control my temper and my mouth.
Yeah. When I was 20, this cute girl said I was "abrupt". I think that was her PC way of saying that I was a total jerk. Funny though, that comment has lived with me ever since.
Gary R. Wheeler wrote:
I like dark beers, BTW.
Agreed! <blockquote class="FQ"><div class="FQA">Gary R. Wheeler wrote:</div>The funny thing is, I think you and I would work well together until the first time we disagreed. Then, look out!</blockquote> But I can be swayed by logic. :) Marc
-
I develop mostly in PHP these days (the last several years actually) and one thing i have noticed about that community, is they are far more adopting of best practices that C/C++/C# at least that is the impression I have of browsing CP all these years. Design patterns do not seem to be disscussed nearly as much as I find they are in the Java community, however OO best practices like OCP, dependency injection, etc I have seen disscussed in C++ literature... It's almost like design patterns, etc are expected learned through osmosis in languages like C# - I realize that Microsoft has the MS patterns repo, but Java also has it's blueprints...but Java forums are usually a lot more buzz with design or architectural, best practice type questions... For instance, behavior driven development...I just spent the last 3-4 days studying TDD/BDD and I can honestly see BDD being the 'better overall' approach. I've already encountered a situation where thinking in terms of behavior versus classical testing has eliminated some potential ambiguity. PHP IMHO is middle ground on best practices. Like ASP.NET, it's easy to learn, so there are tons of eager developers (actually far more than ASP) ready to start hammering out code and maybe make some money (most are horribly developed with no architecture). The lack of any formal frameworks in PHP certainly has sparked some serious interest in PHP to develop a solid, reusable framework (Zend, Symphony, Cake, etc). Probalby more MVC frameworks in PHP than any other language. I wonder if because Microsoft developers (desktop, web, etc) already have all the boilerplate code generated for them, they have no interest in learning about patterns and architecture and thus the lack of interest in keeping up with best practices??? I did a quick search on CP for BDD (Behavior Driven Development) and found 5 matches... If you poke around Google, you will find that BDD is mostly centered around Ruby and perhaps Java. Is it because Java is considered some kind of academic language that the communities seem to promote best practices a little more than say C/C++/C# or even PHP for that matter? Anyways, my question is, I develop in PHP and will likely stay that way as long as PHP keeps moving forward, however I also still enjoy the CP and occasionally tinkering with ideas in C++/MFC and most recently Qt. I feel it nessecary to keep an eye on other languages such as Ruby, Java, etc...just to stay tuned in with current best practices, or at least...bleeding edge development strat
Over the last 4 to 5 years there has been a significant rise of promoting best practices and design patterns in the .Net/C# community. Check out the blogs on http://www.codebetter.com and the mailing list for alt.net community http://tech.groups.yahoo.com/group/cli_dev/. Both sites offer a good discussion of how to use best practices and design patterns in .Net development. Todd
-
Hockey wrote:
I'm finding the only constant in software development is change it self.
Precisely point #1. Point #2 is that there is a glut of techniques, approaches, best practices, and so forth (even the waterfall method of developing an application has its good points) and a dearth in intelligent people that know how to pick and choose the best from all of these methodologies, and a dearth of management that is willing to support what these methodologies really cost. In a nutshell, there's lots of wisdom and little common sense. I was just discussing with my gf, not 10 minutes ago, how there isn't a single company I've ever worked for or contracted for that puts testing in the forefront of budget and time allocations. Where is the company that says "before one line of code is written, we are going to invest in equipment, tools, people and training to develop a solid QA dept"? If there are such companies out there, I haven't heard about them. And that's just one example. Obviously, testing isn't the only priority. If your product doesn't have an architecture that is flexible enough to handle new technologies and new competition, then you're going to lose marketshare as well. If you don't invest in documentation and tech support, you're going to lose marketshare. And so forth. Frankly, all these methodologies are meaningless in the face of the wrong (or even lack of) decisions that are made up front, before any product is ever designed or a line of code is written. And they tend to be meaningless in light of the course corrections made during development as well, that usually never retain the original guidance. Marc
Frankly, all these methodologies are meaningless in the face of the wrong (or even lack of) decisions that are made up front, before any product is ever designed or a line of code is written. And they tend to be meaningless in light of the course corrections made during development as well, that usually never retain the original guidance. ---------- An excellant point. This is one reason why the agile method is gaining popularity. There will ALWAYS be uncertainty upfront. Most of the time, the best way to make the uncertain/unknown known is by experimentation (which is typically called a bad decision if the experimentation leads to an unuseful result, or a good decision if it leads to a useful result). I think too many people think that software development is all development with no research. The reality is there is always a little research that goes into a software project, even if the research is just a survey of currently available code. A lot of these methodologies are just different ways of doing research. You have to recognize that each research project is different, and when you do find a usable answer, to document the idea and then do the development which results in production quality code. -Kent
-
Frankly, all these methodologies are meaningless in the face of the wrong (or even lack of) decisions that are made up front, before any product is ever designed or a line of code is written. And they tend to be meaningless in light of the course corrections made during development as well, that usually never retain the original guidance. ---------- An excellant point. This is one reason why the agile method is gaining popularity. There will ALWAYS be uncertainty upfront. Most of the time, the best way to make the uncertain/unknown known is by experimentation (which is typically called a bad decision if the experimentation leads to an unuseful result, or a good decision if it leads to a useful result). I think too many people think that software development is all development with no research. The reality is there is always a little research that goes into a software project, even if the research is just a survey of currently available code. A lot of these methodologies are just different ways of doing research. You have to recognize that each research project is different, and when you do find a usable answer, to document the idea and then do the development which results in production quality code. -Kent
Momony wrote:
A lot of these methodologies are just different ways of doing research.
Exactly. Or looking at the problem from different perspectives.
Momony wrote:
The reality is there is always a little research that goes into a software project
:) The projects I work on, it seems that most of the software development is a parallel process of researching whether the whole concept is even feasible! I think those are the most fun projects, actually.
Momony wrote:
and when you do find a usable answer, to document the idea
Aye!!! That is so important, and is something I don't see being done (even by myself) leading to a lot of gnashing of teeth when repeating work, and even worse, in understanding later what the steps were that led up to that usable answer. Marc
-
Momony wrote:
A lot of these methodologies are just different ways of doing research.
Exactly. Or looking at the problem from different perspectives.
Momony wrote:
The reality is there is always a little research that goes into a software project
:) The projects I work on, it seems that most of the software development is a parallel process of researching whether the whole concept is even feasible! I think those are the most fun projects, actually.
Momony wrote:
and when you do find a usable answer, to document the idea
Aye!!! That is so important, and is something I don't see being done (even by myself) leading to a lot of gnashing of teeth when repeating work, and even worse, in understanding later what the steps were that led up to that usable answer. Marc
Marc Clifton wrote:
A lot of these methodologies are just different ways of doing research. Exactly. Or looking at the problem from different perspectives.
Hopefully finding the best approach to tackling the problem in the process.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
-
The Write Stuff[^] This article makes the rounds every now and then. Doing it right is very expensive, although in many cases so is doing it wrong.
Even then they issue each Shuttle mission crew with a list of the known problems that are too difficult/expensive to fix in time (or indeed ever) and which should therefore be avoided. "Discrepancy reports cause changes in software to make it match the requirements. Early in the program, the software found its way into the simulators after less verification because simulators depend on software just to be turned on. At that time, the majority of the discrepancy reports were from the field installations. Later, the majority turned up in the SPF. All discrepancy reports are formally disposed of, either by appropriate fixes to the software, or by waiver. Richard Parten said, "Sometimes it is better to put in an 'OPS Note' or waiver than to fix (the software). We are dependent on smart pilots". If the discrepancy is noted too close to a flight, if it requires too much expense to fix, it can be waived if there is no immediate danger to crew safety. Each Flight Data File carried on board lists the most important current exceptions of which the crew must be aware. By STS-7 in June of 1983, over 200 pages of such exceptions and their descriptions existed. Some will never be fixed, but the majority were addressed during the Shuttle launch hiatus following the 51L accident in January 1986." http://www.hq.nasa.gov/office/pao/History/computers/Ch4-5.html[^]
DoEvents: Generating unexpected recursion since 1991
-
Marc Clifton wrote:
A lot of these methodologies are just different ways of doing research. Exactly. Or looking at the problem from different perspectives.
Hopefully finding the best approach to tackling the problem in the process.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
Paul Conrad wrote:
Hopefully finding the best approach to tackling the problem in the process.
Not to be pedantic, but I don't think there is such a thing as a best approach. Rather, there are often several viable approaches, each with their benefits and drawbacks. Marc
-
Paul Conrad wrote:
Hopefully finding the best approach to tackling the problem in the process.
Not to be pedantic, but I don't think there is such a thing as a best approach. Rather, there are often several viable approaches, each with their benefits and drawbacks. Marc
Marc Clifton wrote:
there are often several viable approaches, each with their benefits and drawbacks.
I agree. With many different clients I've had over the years, no one particular process is a magical-cure-all silver bullet. Have to look at each case and weigh out the pro's and con's.
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
Do this long enough and you will come to intimately realize why most of that is utter crap. Most 'best practices' are ways of herding large groups of substandard programmers in a software factory all the while thoroughly killing the productivity of the truly talented who know when to apply those rules and most importantly when not to. I fully understand why they are necessary in a factory setting with cheap labour and it pays to understand them and their philosophy but it reduces the fine art of software development to the level of any production line worker. A good developer, a truly talented and motivated and experienced one, can outperform any number of factory programmers following the ritual of their best practices religion. I say any number because as you add more factory programmers to a problem you get exponentially decreasing productivity.
Hockey wrote:
Anyways, my question is,
? And your question was??? ;)
When everyone is a hero no one is a hero.
John C wrote:
A good developer, a truly talented and motivated and experienced one, can outperform any number of factory programmers following the ritual of their best practices religion. I say any number because as you add more factory programmers to a problem you get exponentially decreasing productivity.
True. But the vast majority of developers work with and are in fact average developers themselves. By definition. So consequently practices that increase the productivity of those developers cannot be ignored.