How Software Companies Die
-
-
Ravi Bhavnani wrote:
This article has graced my refrigerator door since 1995!
Yeah, its old but still interesting don't you think?
-
peterchen wrote:
But is he really dead wrong?
I think so. Let's take the first sentence, the premise to the whole essay: The environment that nutures creative programmers kills management and marketing types - and vice versa. In my personal experience, I've found this to be completely untrue. I have enjoyed relationships with marketing people because they are closer to the customer and come to me asking whether such-and-such could be done, as a result of a conversation they've had with a customer. Conversely, I come up with some cool idea at 3 AM and implement a prototype and show it to a marketing guy, and he falls out of his chair saying "wow, I can't wait to demo this!" I've encountered this in a variety of companies and vertical markets. Granted, others may have other experiences, but I've worked with people that understand that innovation and success come from many different directions, and that working together is the key to success. And I've worked with managers that facilitate that. Take: you might well discover that you're a hundred pounds overweight, your underwear is older than the average first grader, and judging from the number of pizza boxes lying around, it must be spring already. To me, that's the sign of a very unhealthy work environment. And: But you don't care, because your program runs, and the code is fast and clever and tight. You won. Any programmer nowadays that things they've won because their code is fast and clever and tight is incredibly naive. A program is more than the code--it's the documentation, the unit tests, and the usability and marketability. As to: Here's the secret that every successful software company is based on: You can domesticate programmers the way beekeepers tame bees. Why is this restricted to programmers? And frankly, undisciplined programmers is a guarantee for failure. I've been there too, as an undisciplined programmer. You keep these bees from stinging by paying them money. Naive and shortsighted. As to: All successful software companies had, as their dominant personality, a leader who nurtured programmers. But no company can keep such a leader forever. Wow. Two sentences, and I could write paragraphs about how much BS is in them. To be concise, a successful software company is successful because all the people are nurtured and share in a vision. OK, there might be a dominant personality (
You are a rare breed, Marc: someone who can bridge Someone who can stand his own on both sides. That's not an ultra-rare, but maybe one in 5 or ten. I think that's true for most of the "prominent" CPians. What I see as true core of the article is: You can't have all developers as these bridge-types, you simply won't find them. And for the rest of them, all this focus on "suit control" is illogical, a pain and a roadblock to what they consider a good product. If you can give them a bit of what they want, learn to steer them by other mechanisms than shouting, money, promotion and red tape, and know when and how to milk them, you have a workforce that can roll up the world. IMO *that*s the job of a good manager, but they are hard to find as well. One in hundred, maybe? And Card uses a stereotype that is fading out of view. Geeks *are* more presentable now, and there are definitely more people that do programming as a 9-5 job, and do it well. OK, I admit it: there's an empty pizza box on the floor to my left.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighist -
That was written by Orson Scott Card? He should stick to fantasy and science fiction. Marc
Looks to me like he has!
When prediction serves as polemic, it nearly always fails. Our prefrontal lobes can probe the future only when they aren’t leashed by dogma. The worst enemy of agile anticipation is our human propensity for comfy self-delusion. David Brin Buddha Dave
-
I disagree with that entirely. Any market oriented software application is like a Frakenstien monster. In the beginning it must have the driven, passionate genius shooting lighting bolts into it and demanding that it live. Once it is alive and on its feet, however, it needs dispassionante engineers to structure and maintain it. A consumer software application simply cannot survive if it is being tweaked and hacked at after it has been released to the public and is beginning to become successful. It will become unmanagably complex to even the greatest Albert Einstien of programmers in that way. It must be meticulously engineered and planned to survive. Doing that requires meetings and programmers who understand true software engineering, why modifiability is not the same as maintainability, and that code should be designed to become more stable over time, not less stable. The transistion period from 'frankenstien monster' to well engineered application is always a precarious one. Many applications do not make it and most programmers blame it on changing the process they used to create it in the first place. But they are wrong.
Nothing in the entire universe is more useless than morality without authority. A morality free of hyprocrisy is no morality at all.
I disagree with your disagreement. Your implicit assumption that "tweaking" the code consists of random and arbitrary changes is incorrect. Good programmers "tweak" for a reason; a better feature, more reliability, more efficiency. This is called "refactoring", and it generally reduces complexity while improving the program. See http://www.en.wikipedia.org/wiki/Refactoring
-
I disagree with your disagreement. Your implicit assumption that "tweaking" the code consists of random and arbitrary changes is incorrect. Good programmers "tweak" for a reason; a better feature, more reliability, more efficiency. This is called "refactoring", and it generally reduces complexity while improving the program. See http://www.en.wikipedia.org/wiki/Refactoring
Alan Balkany wrote:
This is called "refactoring", and it generally reduces complexity while improving the program.
Yes, but 'refactoring' implies a planned, well managed process, which in turn implies meetings, organizational infrastructure and the application of accepted standards of software engineering.
-
Alan Balkany wrote:
This is called "refactoring", and it generally reduces complexity while improving the program.
Yes, but 'refactoring' implies a planned, well managed process, which in turn implies meetings, organizational infrastructure and the application of accepted standards of software engineering.
"Yes, but 'refactoring' implies a planned, well managed process, which in turn implies meetings, organizational infrastructure and the application of accepted standards of software engineering." Not necessarily. In Extreme Programming, refactoring is typically done by only one or two people. http://www.extremeprogramming.org/rules/refactor.html The bureaucracy is unnecessary. And just because it's done by one or two people doesn't imply it's any less planned. It's actually more efficient this way.
-
I disagree with your disagreement. Your implicit assumption that "tweaking" the code consists of random and arbitrary changes is incorrect. Good programmers "tweak" for a reason; a better feature, more reliability, more efficiency. This is called "refactoring", and it generally reduces complexity while improving the program. See http://www.en.wikipedia.org/wiki/Refactoring
Alan Balkany wrote:
Good programmers "tweak" for a reason; a better feature, more reliability, more efficiency. This is called "refactoring", and it generally reduces complexity while improving the program.
What about average and below average programmers? And who is correctly implementing the new features that the customers are asking for (or demanding via taking their business elsewhere) while the "good" programmer is randomly making adjustments to the software based on their own whims?
-
Naturally, and obviously, in terms of companies themselves the article is wrong. Companies are based on money. Those that make enough survive. Those that don't do Certainly in the modern world a "better" mousetrap is not enough. It either needs to be significantly and provably better or it needs to be completely new to the marketplace before the world will beat a path to your door. And that very, very seldom is the case for any company. Other than that, any programmer that wants to actually get paid for what they do (regardless of what form that compensation takes) would be much better off in focusing on how the company intends to sell the product rather than on how they manage their programmers.
-
I disagree with that entirely. Any market oriented software application is like a Frakenstien monster. In the beginning it must have the driven, passionate genius shooting lighting bolts into it and demanding that it live. Once it is alive and on its feet, however, it needs dispassionante engineers to structure and maintain it. A consumer software application simply cannot survive if it is being tweaked and hacked at after it has been released to the public and is beginning to become successful. It will become unmanagably complex to even the greatest Albert Einstien of programmers in that way. It must be meticulously engineered and planned to survive. Doing that requires meetings and programmers who understand true software engineering, why modifiability is not the same as maintainability, and that code should be designed to become more stable over time, not less stable. The transistion period from 'frankenstien monster' to well engineered application is always a precarious one. Many applications do not make it and most programmers blame it on changing the process they used to create it in the first place. But they are wrong.
Nothing in the entire universe is more useless than morality without authority. A morality free of hyprocrisy is no morality at all.
Actually it's all the craplet features that get socked into v.next that turn it into Frankenstein's Monster. Let a PM at a basic, well designed and written program and they'll say "wait, first let's see what other programs of this nature do". This is the start of the "comparible with other applications feature list". Then some twit says "I've always wanted an application that will do this". This is the start of additions of the 0.1% geek features that seem to get snuck into applications. A 0.1% geek feature is the feature that one tenth of one percent of the users find cool but don't use consistantly. The remaining 99.9% of the users never wanted something like that in the first place. Then add in the upper management "one free feature" chit, simply because they're paid six or seven figures a year. There are typically four or five of these PER RELEASE. Then there's the marketing twits, the ones who feel they have to money above and beyond the initial "sale" price, so they add in online advertising and constant updates to that advertising and how it's delivered to the user. So what was once a decent small and easy to use media player application became the Real Player monstrosity that we all know and hate. And no, I don't work for Real, I just grew to really hate what they did with their product. Orson Scott Card's write-up is 100% dead on target with his description, regardless of when it was written.
Mike Poz
-
"Yes, but 'refactoring' implies a planned, well managed process, which in turn implies meetings, organizational infrastructure and the application of accepted standards of software engineering." Not necessarily. In Extreme Programming, refactoring is typically done by only one or two people. http://www.extremeprogramming.org/rules/refactor.html The bureaucracy is unnecessary. And just because it's done by one or two people doesn't imply it's any less planned. It's actually more efficient this way.
But extreme programming is itself a managment driven initiative. It requires an organizational infrastructure to fully implement. If two programmers simply begin doing extreme programming of their own accord, independent of the rest of the process, it is merely hacking. The entire point of good programming is to produce code that is stable and functional and is maintained not by changing a single line of the exsiting code base but extending it in a consistent way according to well known software engineering patterns. If you are constantly changing the existing code base, extreme programming or no, that code will become more complex and unmanagable over time. Its inevitable, regardless of the quality of your programmers.
-
Actually it's all the craplet features that get socked into v.next that turn it into Frankenstein's Monster. Let a PM at a basic, well designed and written program and they'll say "wait, first let's see what other programs of this nature do". This is the start of the "comparible with other applications feature list". Then some twit says "I've always wanted an application that will do this". This is the start of additions of the 0.1% geek features that seem to get snuck into applications. A 0.1% geek feature is the feature that one tenth of one percent of the users find cool but don't use consistantly. The remaining 99.9% of the users never wanted something like that in the first place. Then add in the upper management "one free feature" chit, simply because they're paid six or seven figures a year. There are typically four or five of these PER RELEASE. Then there's the marketing twits, the ones who feel they have to money above and beyond the initial "sale" price, so they add in online advertising and constant updates to that advertising and how it's delivered to the user. So what was once a decent small and easy to use media player application became the Real Player monstrosity that we all know and hate. And no, I don't work for Real, I just grew to really hate what they did with their product. Orson Scott Card's write-up is 100% dead on target with his description, regardless of when it was written.
Mike Poz
My frankenstein metaphor was merely in reference to the attitudes of those producing it. A large, complex consumer application that has no existing customer base needs an "evil genius" firing lighthing bolts into it to get it to live (to market that is). At that early stage, the only thing that is important is that it work, not that it is designed well. But once it is up and on its feet it must be quickly transformed into something much differnt. If it is to survive on the open market it must be designed in a way that allows it to be easily maintained and extended in order to out pace competitive products.
-
But extreme programming is itself a managment driven initiative. It requires an organizational infrastructure to fully implement. If two programmers simply begin doing extreme programming of their own accord, independent of the rest of the process, it is merely hacking. The entire point of good programming is to produce code that is stable and functional and is maintained not by changing a single line of the exsiting code base but extending it in a consistent way according to well known software engineering patterns. If you are constantly changing the existing code base, extreme programming or no, that code will become more complex and unmanagable over time. Its inevitable, regardless of the quality of your programmers.
"But extreme programming is itself a managment driven initiative." Not necessarily. Often management just wants the job done. Even an individual can choose to use Extreme Programming (XP) to get the job done. It sounds like you're claiming management makes the difference between XP and hacking. That's a distorted view of managment that doesn't reflect reality. "If you are constantly changing the existing code base, extreme programming or no, that code will become more complex and unmanagable over time." Reread the link I gave to refactoring. It tends to make code simpler and more manageable. And code usually goes through periods of constant change. It's called development.
-
Alan Balkany wrote:
Good programmers "tweak" for a reason; a better feature, more reliability, more efficiency. This is called "refactoring", and it generally reduces complexity while improving the program.
What about average and below average programmers? And who is correctly implementing the new features that the customers are asking for (or demanding via taking their business elsewhere) while the "good" programmer is randomly making adjustments to the software based on their own whims?
"What about average and below average programmers?" Below average programmers will turn out below average code regardless of the methodology. Sad but true. "And who is correctly implementing the new features that the customers are asking for (or demanding via taking their business elsewhere) while the "good" programmer is randomly making adjustments to the software based on their own whims?" Refactoring is not making random changes based on whims. See http://www.extremeprogramming.org/rules/refactor.html Simplifying and removing clutter allows features to be added faster and more reliably. Avoiding refactoring allows software entropy to increase, making the code more complex and brittle. This makes it harder to understand, and less reliable. Complexity is evil.
-
"But extreme programming is itself a managment driven initiative." Not necessarily. Often management just wants the job done. Even an individual can choose to use Extreme Programming (XP) to get the job done. It sounds like you're claiming management makes the difference between XP and hacking. That's a distorted view of managment that doesn't reflect reality. "If you are constantly changing the existing code base, extreme programming or no, that code will become more complex and unmanagable over time." Reread the link I gave to refactoring. It tends to make code simpler and more manageable. And code usually goes through periods of constant change. It's called development.
Alan Balkany wrote:
It sounds like you're claiming management makes the difference between XP and hacking.
Good management does indeed make the difference. The lack of good management, not lack of good programming, is the greatest problem the software industry has. Any one can write good code if properly managed.
Alan Balkany wrote:
And code usually goes through periods of constant change.
Not if it is properly designed. Obviously, all code has bugs. But code can be designed so that once it is running cleanly it never again needs to be touched. If changes are necessary, the current code base is extended to provide those changes but the existing code base is never changed. Achieving that requires good managment and cannot be achieved independently by programmers deciding on their own to do things one way compared to another. Programming is not about being some kind of lone wolf genius (except, again, during the initial start up period of an application's existence), it is about the methodical application of time tested software development techniques.
-
Alan Balkany wrote:
It sounds like you're claiming management makes the difference between XP and hacking.
Good management does indeed make the difference. The lack of good management, not lack of good programming, is the greatest problem the software industry has. Any one can write good code if properly managed.
Alan Balkany wrote:
And code usually goes through periods of constant change.
Not if it is properly designed. Obviously, all code has bugs. But code can be designed so that once it is running cleanly it never again needs to be touched. If changes are necessary, the current code base is extended to provide those changes but the existing code base is never changed. Achieving that requires good managment and cannot be achieved independently by programmers deciding on their own to do things one way compared to another. Programming is not about being some kind of lone wolf genius (except, again, during the initial start up period of an application's existence), it is about the methodical application of time tested software development techniques.
"Any one can write good code if properly managed." "If changes are necessary, the current code base is extended to provide those changes but the existing code base is never changed. Achieving that requires good managment and cannot be achieved independently by programmers deciding on their own to do things one way compared to another." These statements contradict reality. No amount of management can make bad programmers produce reliable and maintainable code. New requirements often require changing existing code. Implementation decisions ARE made by programmers; it's called "development", and it's what they're hired to do.
-
peterchen wrote:
But is he really dead wrong?
I think so. Let's take the first sentence, the premise to the whole essay: The environment that nutures creative programmers kills management and marketing types - and vice versa. In my personal experience, I've found this to be completely untrue. I have enjoyed relationships with marketing people because they are closer to the customer and come to me asking whether such-and-such could be done, as a result of a conversation they've had with a customer. Conversely, I come up with some cool idea at 3 AM and implement a prototype and show it to a marketing guy, and he falls out of his chair saying "wow, I can't wait to demo this!" I've encountered this in a variety of companies and vertical markets. Granted, others may have other experiences, but I've worked with people that understand that innovation and success come from many different directions, and that working together is the key to success. And I've worked with managers that facilitate that. Take: you might well discover that you're a hundred pounds overweight, your underwear is older than the average first grader, and judging from the number of pizza boxes lying around, it must be spring already. To me, that's the sign of a very unhealthy work environment. And: But you don't care, because your program runs, and the code is fast and clever and tight. You won. Any programmer nowadays that things they've won because their code is fast and clever and tight is incredibly naive. A program is more than the code--it's the documentation, the unit tests, and the usability and marketability. As to: Here's the secret that every successful software company is based on: You can domesticate programmers the way beekeepers tame bees. Why is this restricted to programmers? And frankly, undisciplined programmers is a guarantee for failure. I've been there too, as an undisciplined programmer. You keep these bees from stinging by paying them money. Naive and shortsighted. As to: All successful software companies had, as their dominant personality, a leader who nurtured programmers. But no company can keep such a leader forever. Wow. Two sentences, and I could write paragraphs about how much BS is in them. To be concise, a successful software company is successful because all the people are nurtured and share in a vision. OK, there might be a dominant personality (
Marc Clifton wrote:
In my personal experience, I've found this to be completely untrue. I have enjoyed relationships with marketing people because they are closer to the customer and come to me asking whether such-and-such could be done, as a result of a conversation they've had with a customer.
Try working for a company who has the VP of Marketing running the Development branch of the org chart. Trust me, it'll kill.
This statement was never false.
-
"What about average and below average programmers?" Below average programmers will turn out below average code regardless of the methodology. Sad but true. "And who is correctly implementing the new features that the customers are asking for (or demanding via taking their business elsewhere) while the "good" programmer is randomly making adjustments to the software based on their own whims?" Refactoring is not making random changes based on whims. See http://www.extremeprogramming.org/rules/refactor.html Simplifying and removing clutter allows features to be added faster and more reliably. Avoiding refactoring allows software entropy to increase, making the code more complex and brittle. This makes it harder to understand, and less reliable. Complexity is evil.
Alan Balkany wrote:
Below average programmers will turn out below average code regardless of the methodology. Sad but true.
Yet there will be as many of those as the excellent ones. And it completely ignores that I mentioned average programmers as well, who will be the largest pool.
Alan Balkany wrote:
Refactoring is not making random changes based on whims. See http://www.extremeprogramming.org/rules/refactor.html Simplifying and removing clutter allows features to be added faster and more reliably. Avoiding refactoring allows software entropy to increase, making the code more complex and brittle. This makes it harder to understand, and less reliable. Complexity is evil.
Thank you for explaining a term that I already understood and had nothing to do with what I was discussing. How refactoring works is not the point - the point is what reason drove the refactoring in the first place. The benefits of refactoring is not the point either - the point is how the decision was reached in the first place that deemed that a refactor was needed. If there is an identified problem that is deemed, by the company and not the programmer, that requires fixing then that is a process that is driven by the company and not the programmer. By definition. Presumably the same process that would allow a decision to be reached as to whether one specific part of the code should be re-worked versus whether a new feature in another part of the code should be added. That decision process is driven by the business and not the whims of the individual programmer. Such a process should at least allow for input from other sources besides programmers. And since programmers do not generate income (versus actual sales) then some consideration must be given as to the nature of what the actual revenue impact is. And that is often more important than what an individual programmer wants to do. Finally, not to mention, not all programmer driven initiatives are in fact refactors. I doubt that adding a flight simulator into a spreadsheet program is a "refactor".