The problem with software development is that people who don't know what they are doing are controlling it.
If management knew what they were doing then...
They wouldn't hire programmers who don't know what they are doing.
They wouldn't just go through the motions of following the process-of-the-week just to say that they have a process.
They would tailor a process to work for their organization by picking and choosing intelligently aspects from many software development processes.
They wouldn't hire overpriced consultants (who have supposedly read books on software development processes) to tell them what process to pick.
They would hire architects to design systems before letting coders start their work.
They would hire QA professionals who understand testing terms like unit testing, black-box testing, white-box testing, code coverage, regression testing, etc.
They would read books on software development processes.
They would read books on software management.
They would read books on software.
They would read books.
They would be able to read.
If you want to change the quality of software, you must first determine why the quality is so bad. Economics is the biggest reason for quality being poor. The reward system in place is one that rewards the company who grabs the biggest market share. Once a product has a stronghold on the marketplace, it is extremely difficult to replace it. Software becomes a de facto standard, e.g. Microsoft WORD.
So how does a company grab the biggest slice of the marketplace pie? They do so by getting to market first. How do they get to market first? By cutting every possible corner imaginable to meet a ridiculous deadline and releasing a product of poor quality.
All other reward systems stem from this one. Imagine the case where a company has two programmers. The first hacks a bunch of code together and makes the ridiculously short deadline. The second programmer misses the deadline but produces a much more stable product. Now once the first programmers code starts to fail, the first programmer has to "save" the company by providing short-term quick fixes to the code, reducing the quality of the code further. Management views this individual as a key individual; key because they can't operate without him. The second individual is hardly noticed, except for delivering late, which is considered aberrant behavior.
So imagine the case where both of these programmers are leaving the company. Which individual do you think the company is going to bend over backwards to keep?
Economics, being the ultimate reward system for business, dictates that software development will never be able to do what hardware engineers have been doing for years, create micro-components. In hardware, you can create an AND gate and package many of these gates into a chip. This chip can be mass-produced and sold at a reasonable price. Every time a circuit is produced with this part, the manufacture make a little money for each part purchased.
In software, we can't make a simple component and standardize on it. If we created a component, e.g. a component that compares two dates to see if something has expired, and tried to sell it, what would people pay for it? Maybe a dollar. Most people would look at this component as so simple, they'd rather develop their own. But even if they did buy it, they can make millions of copies of this component with no additional cost. It would be the analogy of instead of buying an AND gate for 50 cents, you bought the AND gate factory for 50 cents. The hardware industry would have gone out of business years ago under such a system.
Software suffers from the economics constraints more than language problems, management issues, bad programmers, etc. Anyone can buy book after book on proper techniques for managing a team of developers using a myriad of development processes. The reason we see management pay only lip service to process is because the reward system for businesses doesn't reward quality or standards.
This is the real problem to solve (if there is a solution). Would companies pay royalties for components that were used in their products? Highly unlikely. Will people stop paying for new software because it is too buggy? Maybe, but it is usually better to use buggy software than no software at all.
After almost 20 years, I have given up on the software industry. As soon as I can get out, I will. The better you get in software design and development, the harder it is to operate in this environment. I don't blame companies for operating the way they do. They are rewarded for doing so.
So if you want to change behavior then change the reward system. Good luck.
Component Oriented Programming is the future. COP is not COM, EJB or CORBA. Those are heavy weight components. I talking about very light weight components down at the language level. COP uses containment to reuse functionality.
My idea of a good COP language would have the following attributes: uses containment and interfaces (instead of inheritance), has a restrictive referencing model where encapsulation and proper coupling is enforced and guaranteed by the language, automatic reclamation of memory eliminating the need for garbage collectors but still freeing the developer from explicit deletes (best of both worlds), deterministic destruction of components (since no garbage collector), P-Code compiled once when transferred to a new platform (not every time the component is loading into memory), a single outer component that replaces the virtual machine which is now unnecessary (it is this outer component that ported from machine to machine), coupling of components are done only at the interface level by their common container (siblings never call each other directly), etc.
Well so much for that pipe dream. Until the economics of language development change, there will be very little advancements made. Since Java is now free, the economics have changed drastically. Another harsh reality is that most languages still allow the developer to easily violate some pretty basic laws of good design, e.g. low coupling and encapsulation. What we need is a language that supports known design laws.
What we don't need is more design patterns. Design patterns are mostly mechanisms to get around bad language design. Many of the books written on "pitfalls" of a particular language stem from inheritance. If you don't believe me then pick one up and count them. A good 80% of all rules/laws of C++ or Java stem from inheritance.
Another major problem is programmers. We are all object oriented programmers now. Unfortunately, most of us object-oriented programmers still think Java is an object-oriented language. Well, I hate to be the one to break the news, but it is not. You need three things to be an OO language: inheritance (yuck), polymorphism and encapsulation. Since every object is a reference in Java, you'd have to clone every object going in and out of an object to properly protect that object from outside access (encapsulation). Since cloning cannot be guaranteed to be a deep copy (most are shallow copies), then you have to serialize the object to a memory stream and back into the new object assuming all objects are serializable which many are not.
Most "programmers" aren't. We think that inheritance is the new silver bullet. And we are quite religious about this. Most programmers don't know what coupling is, don't understand what the fragile base class is, don't even think about encapsulation and wouldn't know a black-box approach to coding if it bit them in the ass.
Good design practices should dictate the language requirements. Low coupling is the most important design concept ever. Every language I've worked with has intrinsically supported high coupling. Many design patterns that have been developed should be part of the language, e.g. delegation, publisher/subscriber, singletons. Most design patterns would go away with a properly designed language.
It is extremely difficult and many times impossible to develop systems that follow proper design practices because of the brain-dead languages that we are forced to use. Until some company with a lot of money (not Microsoft because they have never innovated anything) who has a lot to gain by creating a language that produces robust systems exists (if ever), we will be stuck using plastic spoons to dig our graves.
Slashdot Mirror
The problem with software development is that people who don't know what they are doing are controlling it.
If management knew what they were doing then...
They wouldn't hire programmers who don't know what they are doing.
They wouldn't just go through the motions of following the process-of-the-week just to say that they have a process.
They would tailor a process to work for their organization by picking and choosing intelligently aspects from many software development processes.
They wouldn't hire overpriced consultants (who have supposedly read books on software development processes) to tell them what process to pick.
They would hire architects to design systems before letting coders start their work.
They would hire QA professionals who understand testing terms like unit testing, black-box testing, white-box testing, code coverage, regression testing, etc.
They would read books on software development processes.
They would read books on software management.
They would read books on software.
They would read books.
They would be able to read.
So how does a company grab the biggest slice of the marketplace pie? They do so by getting to market first. How do they get to market first? By cutting every possible corner imaginable to meet a ridiculous deadline and releasing a product of poor quality.
All other reward systems stem from this one. Imagine the case where a company has two programmers. The first hacks a bunch of code together and makes the ridiculously short deadline. The second programmer misses the deadline but produces a much more stable product. Now once the first programmers code starts to fail, the first programmer has to "save" the company by providing short-term quick fixes to the code, reducing the quality of the code further. Management views this individual as a key individual; key because they can't operate without him. The second individual is hardly noticed, except for delivering late, which is considered aberrant behavior.
So imagine the case where both of these programmers are leaving the company. Which individual do you think the company is going to bend over backwards to keep?
Economics, being the ultimate reward system for business, dictates that software development will never be able to do what hardware engineers have been doing for years, create micro-components. In hardware, you can create an AND gate and package many of these gates into a chip. This chip can be mass-produced and sold at a reasonable price. Every time a circuit is produced with this part, the manufacture make a little money for each part purchased.
In software, we can't make a simple component and standardize on it. If we created a component, e.g. a component that compares two dates to see if something has expired, and tried to sell it, what would people pay for it? Maybe a dollar. Most people would look at this component as so simple, they'd rather develop their own. But even if they did buy it, they can make millions of copies of this component with no additional cost. It would be the analogy of instead of buying an AND gate for 50 cents, you bought the AND gate factory for 50 cents. The hardware industry would have gone out of business years ago under such a system.
Software suffers from the economics constraints more than language problems, management issues, bad programmers, etc. Anyone can buy book after book on proper techniques for managing a team of developers using a myriad of development processes. The reason we see management pay only lip service to process is because the reward system for businesses doesn't reward quality or standards.
This is the real problem to solve (if there is a solution). Would companies pay royalties for components that were used in their products? Highly unlikely. Will people stop paying for new software because it is too buggy? Maybe, but it is usually better to use buggy software than no software at all.
After almost 20 years, I have given up on the software industry. As soon as I can get out, I will. The better you get in software design and development, the harder it is to operate in this environment. I don't blame companies for operating the way they do. They are rewarded for doing so.
So if you want to change behavior then change the reward system. Good luck.
My idea of a good COP language would have the following attributes: uses containment and interfaces (instead of inheritance), has a restrictive referencing model where encapsulation and proper coupling is enforced and guaranteed by the language, automatic reclamation of memory eliminating the need for garbage collectors but still freeing the developer from explicit deletes (best of both worlds), deterministic destruction of components (since no garbage collector), P-Code compiled once when transferred to a new platform (not every time the component is loading into memory), a single outer component that replaces the virtual machine which is now unnecessary (it is this outer component that ported from machine to machine), coupling of components are done only at the interface level by their common container (siblings never call each other directly), etc.
Well so much for that pipe dream. Until the economics of language development change, there will be very little advancements made. Since Java is now free, the economics have changed drastically. Another harsh reality is that most languages still allow the developer to easily violate some pretty basic laws of good design, e.g. low coupling and encapsulation. What we need is a language that supports known design laws.
What we don't need is more design patterns. Design patterns are mostly mechanisms to get around bad language design. Many of the books written on "pitfalls" of a particular language stem from inheritance. If you don't believe me then pick one up and count them. A good 80% of all rules/laws of C++ or Java stem from inheritance.
Another major problem is programmers. We are all object oriented programmers now. Unfortunately, most of us object-oriented programmers still think Java is an object-oriented language. Well, I hate to be the one to break the news, but it is not. You need three things to be an OO language: inheritance (yuck), polymorphism and encapsulation. Since every object is a reference in Java, you'd have to clone every object going in and out of an object to properly protect that object from outside access (encapsulation). Since cloning cannot be guaranteed to be a deep copy (most are shallow copies), then you have to serialize the object to a memory stream and back into the new object assuming all objects are serializable which many are not.
Most "programmers" aren't. We think that inheritance is the new silver bullet. And we are quite religious about this. Most programmers don't know what coupling is, don't understand what the fragile base class is, don't even think about encapsulation and wouldn't know a black-box approach to coding if it bit them in the ass.
Good design practices should dictate the language requirements. Low coupling is the most important design concept ever. Every language I've worked with has intrinsically supported high coupling. Many design patterns that have been developed should be part of the language, e.g. delegation, publisher/subscriber, singletons. Most design patterns would go away with a properly designed language.
It is extremely difficult and many times impossible to develop systems that follow proper design practices because of the brain-dead languages that we are forced to use. Until some company with a lot of money (not Microsoft because they have never innovated anything) who has a lot to gain by creating a language that produces robust systems exists (if ever), we will be stuck using plastic spoons to dig our graves.
I am not holding my breath.