Well, you can say it's impossible all you like, but since I've actually done it and had it work very well, I gather you're not trying to convince me. I'll assume that this is your somewhat rancorous way of asking questions.
This can only happen when changes are undocumented and there was probably little or shoddy overall design doc in the first place.
Documentation is not a solution to the problem of increased cost of change over time. Why? Three reasons.
Documentation duplicates information in the code, often multiple times. Changing the code requires finding all of the places in the documentation that relate and changing those, too.
Because each change increases the amount of documentation, you've made it that much harder for anybody to really understand the existing system, and that understanding takes time.
Your duplicated chunks of information will drift out of sync over time. Any maintenance programmer knows the feeling: the docs say two different things, the code says a third, and if you ask somebody, they think it should work yet another way. (This is the same reason that copy-and-paste coding doesn't work.)
Further, even if you could document perfectly, you still haven't solved the problem of design drift. Local patches without refactoring increase design complexity. No matter what documentation you have, it's still hard to understand. The solution isn't to generate yet more paper, it's to reduce the size and complexity of the code.
As Martin Fowler says, "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
If you have an adequate communication device and keep it updated, you cannot reach a level where "nobody really understands it".
You seem to be mistaking documentation for knowledge. Paper doesn't do anything by itself; what you need is knowledge in the heads of people. The US legal system is extensively documented, but if you need something done, you talk to a lawyer with experience in the area.
The way you maintain skills is to use them. The my-god-don't-touch-it school of maintenance denies people the experience necessary to understanding what's going on. By continously looking for ways to improve the code, you engage with the code in a way impossible for people scared of making changes.
Of course, that fear made sense on a traditional project. But with source code control, good unit tests, good acceptance tests, and somebody pairing with me, I don't have any need to be afraid. If I'm worried about something, I write a test and let the computer do the worrying for me.
In fact, its a horrible idea for maintenance. The goal of maintenance is to fix bugs to an existing codebase. You want to do this with the minimum need to retest, and usually at a minimal of human resources.
Clearly, you don't know much about Extreme Programming. An XP project ends up building two complete test suites. The unit tests are written from the perspective of the developers, and the acceptance tests are written from the traditional QA perspective.
On my current XP project, the whole test suite gets run every time somebody checks in a code change; any failures and the computer yelps until we fix things. When we do releases we manually poke around a bit, but that's mainly superstition; if we were really afraid that something could be broken without us knowing, that would be a sign we hadn't written very good tests.
This means you want to cause the minimal amount of change to the codebase possible. [...] With maintenance you don't EVER want to refactor- refactoring has a much higher likelyhood of introducing bugs, requiring more extensive and expensive regression testing. You want to design the change, apply it, and then never touch that part again if possible.
This is only true if changing things is likely to introduce bugs. If regression testing is automated, it's cheap. And if you have full test suites and do pair programming, you are unlikely to introduce bugs. (At my current shop, we have bug rates well below one per developer/month.) That means that there's no reason not to refactor if the code needs it.
And there's a big reason to refactor. Your approach of fearfully making localized changes to the code without refactoring means that the broad design gets more and more distorted. Over time, the system gets squirrely enough that nobody really understands it, which increases the cost of change and increases risk. Eventually, your approach leads to the abandonment of the code base and a big fresh start. That's very expensive.
Extreme Programming, on the other hand, is designed to be sustainable over the long haul. Instead of assuming that the code base will eventually become moribund, XP tries to answer the question, "How can we keep this code good enough to work on forever, no matter how many changes are requested?"
They'll pump out more code than you're slowbie QA people can handle.
Hooray! That's what I want: people pumping out code.
I think you should next take your theory to Boeing; they'll be excited to hear a cheap way to get their workers to rivet more metal onto planes. And I'm sure the customers will be excited when they hear that the cost per pound of their planes will go down a lot.
Indeed, throughout my career I have noticed that projects usually have failed for reasons *other* than the methodology/approach being used.
This strikes me as a sign that the methodology in question is incomplete.
That's not to say that a methodology should be completely idiot-proof. But it should be possible for humans to do. It shouldn't solve all their problems, but the methodology should make the problems obvious as soon as possible, and give a good framework for thinking about solving them.
One finally interesting area is maintenance. It probably accounts for more than 80% of the development resources, yet I have never seen any formal method/strategy/tool for handling maintenance/change requests/bugfixes. Is this because maintenance is unsexy?
Extreme Programming qualifies. The way they look at it, after the first iteration is complete you're in maintenance mode. A steady stream of change requests come in, and every week you do the most important week's worth.
This is a good way to look at things, because it prevents you from shortchanging things that are important but not urgent. In Extreme Programming, there is no magic date when the project is "done", so there's no excuse for letting things get messy.
"You don't even bother doing a cost benefit analysis to compare a $500,000 machine to worker who earns 70 cents a day."
You might not. Some managers might not. But smart people go beyond simple labels.
Educated workers are much more productive and can do work of much higher quality. If the above comparison were the only thing that mattered, nothing would be manufactured in the US. But all the brute labor in China won't replace a semiconductor fab.
He also explained that the 70 cents a day was a NAFTA wage cap and the coompany had to provide free food and shelter to its employees because they couldn't live on the maximum salary they were legally allowed to have.
Once you find me a reference on a "NAFTA wage cap", I'll cease to roll my eyes at this. I've heard of nothing in NAFTA that imposes a salary cap, and the Mexican minimum wage is many times higher than that, and the median wage higher still.
That's not a slam against Indians (or other off-shoring cultures), but more a fact of life. They are disconnected from the project to such a degree that they have no real grasp of it other than to produce *exactly* what the specs document says. This is the same type of problem you see in using consulting firms like Anderson, nay, Accenture in developing your software.
Agreed! Personally, I'm not planning on getting out of the industry, but I do plan to work only on projects using agile methods like Extreme Programming. Why? Because methods like XP tightly integrate the businesspeople and the techies in a way that is impossible if you're working in different time zones.
Not only is this more efficient than a document-driven process, but it's so much more flexible that you can keep ahead of your competitors using traditional processes. For projects that need speed and flexibility, outsourcers can't compete, whether they're in an Accenture office or in Bangalore.
Are you serious about auto jobs? Have you seen Detroit or Flint Michigan? Auto jobs, by and large, ARE gone!
The Detroit car companies did get their asses kicked, but that doesn't prove much about offshoring. You have to add back in all the jobs that foreign car manufacturers have created in the US. And you can't count the jobs lost to technological improvement; automotive companies invest heavily in technology that reduces their labor costs, which often means a loss of jobs.
I did some consulting for a large, software-focused company that has been trying some outsourcing. The have a standard company measure for units of functionality, and tried sending some projects to Indian programmers and measuring the cost. All things accounted for, the cost per unit was about 50% lower, not the radical 80-90% off that you hear.
But that didn't mean that they were going to do a lot of outsourcing. For the core parts of their software, they wanted in-house people to work on it; it's too risky putting the crown jewels in the hands of hired mercenaries. And the barriers to communication were large enough that many kinds of projects couldn't really be sent, because transferring the appropriate knowledge is too hard.
People with ringtones on in theaters is a social problem. Social problems cannot be solved by technical means.
That's a reasonable heuristic, but it's foolish to state it as a general law and then make deductions from it. Theft is a social problem, but very few people bother stealing from vending machines these days because the anti-theft technology makes it so hard.
And really, I don't think this is a social problem. The main problem here is not that people are trying to be jerks, it's that they forget to turn off their phones and may thoughtlessly and reflexively answer them when they ring.
Even if you jam cellphones, they're still going to be talking loudly, or having some kid playing his gameboy, or crying, or throwing popcorn, or whatever. It won't solve anything.
Good theory. Alas, my data doesn't support it. The last three times this happened to me, it was in the middle of the movie and the culprit had been quiet up until then and was apologetic afterwards. So although jamming might not, technically, solve anything, it would improve things a fair bit.
What they should do is take the money they were going to use for this, hire a couple of bouncers[...]. End of story.
Ok, figure it costs $5k per theater to set this up. How long can you pay a bouncer per theater on that money? I make it less than half a year before you let the bouncers go. What do you plan to do then?
How about the eight years of business cards I've handed out with the same address? Or the long-lost college pals who get in touch via the email address I still have after thirteen years? Or perhaps it's just a stubborn refusal to yield a medium I've spent twenty years using to a handful of greedy sociopaths.
Let's turn it around: What's your excuse for giving in to them?
In particular, programming methodologies such as Extreme Programming that require greater management involvement in the coding process will be treated with scorn; management wants less involvement, not more. As to whether or not the code actually works - once it's out the door and bonuses are in hand, who cares?
Well, for one, companies that want to make money. A company may be able to get away with shipping crap for a little while, but it's rare that somebody can do it for long. Why? It's not just that customers notice. A cruddy code base is hard to build on, so low initial quality means slow development for the life of the code base.
Once a manager has experienced doing a project right, it's pretty rare they want to go back to the old, painful, unproductive way of doing things.
Some of us more experienced developers do not think it is the holy grail. It looks like you can make as much mistake as in convetional languages. Also, development with a GUI (see at www.kc.com) is much more cumbersome.
Personally, I think this is akin to VRML: it's an idea that seems simple and obvious but will turn out to be a huge waste of time and money.
I think that tools that help you visualize things are great, but I think the way to greater productivity is through the kind of automation provided by modern editors like IntelliJ IDEA. It may be that one day somebody will develop a visual programming environment that lets you be as productive as code, but I think it will take a radically different programming language and a different physical user interface. For now I think it makes as much sense as an all-visual version of Microsoft Word for novelists.
The most effective techniques for finding defects is still code review. It seems that one of the pair programming is a very good way of doing code review.
Strongly agreed. Code reviews can be nice, but frequently the good suggestions come too late to be worth implementing. Pair programming gets you the feedback you need before you've gone too far down the wrong path.
Do NOT get the engineer who wrote the code to also write the test. It's fairly fundamental - the engineer who wrote it will have a prejudiced view of what should/will work. Get someone else to do it and get a valuable fresh insight.
You're acting as if it's either/or. The proper answer is both.
Unit tests verify that the code does what the programmer says it should. If the programmer does test-driven development, the engineer is much less likely to do the kind of shoddy testing you're worried about. The problem is further lessened if you do pair programming.
But I also think it's important to have tests written by other people, ones written from the perspective of the people who say what the requirements are. Those not only verify that the system works, but that the engineers built the right system.
The great thing about unit tests is that programmers can adopt them on their own. There's no need for separate QA, managerial approval, extra meetings, or anything like that. You can just write them because it makes your work easier. And boy howdy, it does.
But write which tests first? There are so many possible. Usually there are more ways for something to malfunction than for it to function correctly.
You write a test first. Then you make it pass. Which test? Whichever the most important one is.
We don't like the way that works in practice", you haven't wasted time writing 10 tests. Whereas if you do it the other way round, they can only find out they don't like it after you've written the 10 tests AND the actual code.
This would imply that writing the test slows things down. In my experience, and that of most other people who do test-driven development, having tests speeds things up because you spend less time debugging.
Doing the tests first also helps make sure you're doing the right thing. Writing a test case requires you to be more clear about what you're doing, so that you are forced to clarify the requirements before you write the code.
Your suggestion probably works well for certain scenarios, but appears counterproductive for many others.
That's a plausible theory. But having tried it both ways, I think it's incorrect. The only real way for you to find out is to try it yourself. Pick up Kent Beck's Test-Driven Development: By Example and give it a go.
If you write some code that reads several rows from a database and as a result writes a bunch of rows in another table, you need to run scripts before and after your unittest.
When something is hard to do, one option is to try a different way of doing this.
In the case of database interaction, mocking things out is a good step. A unit test might only verify that your code produces the proper SQL and interprets mock ResultSet objects properly; it need not talk to a real database.
Also, you probably shouldn't be scattering SQL everywhere throughout your app. If you isolate the SQL to a mapping layer, it's pretty easy to test that the mapping layer works with the database; then all the rest of the unit tests can use a mock database interface. Not only is that easier to test, but it's much, much faster.
It's of course all doable, it's just that it's sometimes more work than writing the method itself.
True, but irrelevant. The time to compare it to is not just the amount of time it takes to write the code, but also the amount of time you spend debugging that code over its lifetime. I do test-driven development in an XP shop. Our bug rates in production are lower than one per developer-month, and I spend perhaps 10 minutes a week using the debugger.
In my experience, the time and stress saved by doing extensive testing is well worth the time we spend writing tests. As a bonus, we spend little time writing documentation; if you want to know what some object is supposed to do, the unit tests make it pretty clear.
But I've come to realize, it [unit testing] just doesn't help to reduce big errors in system level design.
That's like saying that street maps don't tell you what the continent looks like. It's technically true, but it seems to miss the point.
Unit tests are for testing relatively small chunks of work. If you want to be sure the pieces work together, you do testing at higher levels. I think both are necessary for a solid system.
Personally, I think of my high-level tests as executable requirements. Every time I check in code, a server makes sure that all our tests, both unit and end-to-end, run happily. That's a big step up from the traditional requirements phone book that most people don't use except as an aid to yelling at someone.
I don't want to spend the rest of my life using my skills to make someone else money.
I'm sorry to say it, but this attitude alone disqualifies you from running your own business yet.
As a contractor or a consultant, you have to figure out how you can make other people money. That's the whole point of it; if they're not going to make a lot more money through your efforts than what you're charging, then they'd be fools to hire you, wouldn't they?
As an independent, you will spend a lot of time selling yourself. And unless you are able to seek out and clearly explain the benefits of win/win situations, you will have a terrible time of it. And even once the sale is made, you'll always need to explain things in business terms. When they have to choose between, say, Java or.NET, they don't want to hear about technical merits. They want to know which has lower development costs, which is easier for new employees to learn, how the choice affects maintenance costs, and generally what impact the choice has on their bottom line.
So I'd say that you should just go out and get a regular job while you learn more about how the business world works. The best choice might be to start with some small contract development shop, somewhere you can have regular contact with the partners. Alternatively, consider working for a while on the other side of the fence, doing something where you help manage the purchase of technology services. Either one would be a good environment to see what it takes to succeed once you go on your own.
OTOH, you will never hear the FedGov call a voter/taxpayer what they really need to be called: a dumbass.
Honestly, I think the government should be willing to call more people dumbasses.
But if you're in business, it's hard to make the argument that it's ok to write X% of your customers off as fuckwits, especially if doing so may lead to people getting killed. The challenge when making any consumer product is to make it idiot-proof but still appealing to people who aren't dolts.
Of course, it's fun for smart people to yuck it up about dumb people, just as it's fun for the socially skilled to laugh at the dorky ways of the average Slashdotter. But when you're building things for consumers, I don't think there's much place for that attitude.
Show me a car that can't stop from any speed in under two minutes and I'll show you an engineer or two in the unemployment line.
Perhaps you were in a hurry and didn't have time to read all of his post. He's talking about with the throttle stuck open. If you think you can do it in under two minutes, I encourage you to upload the video of you trying.
I search for the book, go to the first page. I then download/save the next two pages. Then, I search for a line of text on the second page, go to that page, and then have the NEXT two pages available to me. If I keep doing this, I can read the entire book, although it may take a while.
Until somebody actually does this successfully, I'll remain skeptical that it will work. And anybody who is this lame strikes me as unlikely to buy the book anyhow, so it seems like there's no big loss.
major publishers to prove to Amazon and themselves that it actually eats sales rather than driving them -- the consensus of the publishing industry.
This is potentially true for books where a small snippet will do. Of course, that's exactly the kind of information that the Internet is already making available for free. There are already a zillion recipes on line, there's lots of technical information, and Wikipedia proves that it can be done for any sort of quick-and-easy reference.
On the other hand, I think it helps a lot of other books. Anything where you need a linear flow or large chunks of text, including all fiction and most non-fiction published today, doesn't seem vulnerable to attack-via-quick-peek. As others point out, for those it serves the same purpose that leafing through at the bookstore does. I can point to several books on my shelf that I only bought because I could preview it on line, including a couple from new authors that I otherwise wouldn't have touched.
It would have died a long time ago except that it is the pet project of someone high up in Amazon.
Oh, you mean like the customers?
A quick tip for your publishing pals: trying to stuff the digital genie back in the bottle won't work. Like it or not, the Internet is changing the economics of producing and selling information in ways both obvious and subtle. Innovating is great. Rolling with it is good. Mulishly resisting it is ridiculous.
Remember what the Japanese auto manufacturers did to the car industry, and how stubbornly the US carmakers tried to stick with old methods? You can see where it got them. And the Japanese just figured out how do things a bit more smoothly and efficiently. That's nothing compared to the potential of the Internet's impact on any digitizable commodity.
Slashdot Mirror
the public pain threshhold? WTF is this guy talking about?
Yeah, if that were all it took, television would be as extinct as travel by zeppelin.
Well, you can say it's impossible all you like, but since I've actually done it and had it work very well, I gather you're not trying to convince me. I'll assume that this is your somewhat rancorous way of asking questions.
This can only happen when changes are undocumented and there was probably little or shoddy overall design doc in the first place.
Documentation is not a solution to the problem of increased cost of change over time. Why? Three reasons.
- Documentation duplicates information in the code, often multiple times. Changing the code requires finding all of the places in the documentation that relate and changing those, too.
- Because each change increases the amount of documentation, you've made it that much harder for anybody to really understand the existing system, and that understanding takes time.
- Your duplicated chunks of information will drift out of sync over time. Any maintenance programmer knows the feeling: the docs say two different things, the code says a third, and if you ask somebody, they think it should work yet another way. (This is the same reason that copy-and-paste coding doesn't work.)
Further, even if you could document perfectly, you still haven't solved the problem of design drift. Local patches without refactoring increase design complexity. No matter what documentation you have, it's still hard to understand. The solution isn't to generate yet more paper, it's to reduce the size and complexity of the code.As Martin Fowler says, "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
If you have an adequate communication device and keep it updated, you cannot reach a level where "nobody really understands it".
You seem to be mistaking documentation for knowledge. Paper doesn't do anything by itself; what you need is knowledge in the heads of people. The US legal system is extensively documented, but if you need something done, you talk to a lawyer with experience in the area.
The way you maintain skills is to use them. The my-god-don't-touch-it school of maintenance denies people the experience necessary to understanding what's going on. By continously looking for ways to improve the code, you engage with the code in a way impossible for people scared of making changes.
Of course, that fear made sense on a traditional project. But with source code control, good unit tests, good acceptance tests, and somebody pairing with me, I don't have any need to be afraid. If I'm worried about something, I write a test and let the computer do the worrying for me.
In fact, its a horrible idea for maintenance. The goal of maintenance is to fix bugs to an existing codebase. You want to do this with the minimum need to retest, and usually at a minimal of human resources.
Clearly, you don't know much about Extreme Programming. An XP project ends up building two complete test suites. The unit tests are written from the perspective of the developers, and the acceptance tests are written from the traditional QA perspective.
On my current XP project, the whole test suite gets run every time somebody checks in a code change; any failures and the computer yelps until we fix things. When we do releases we manually poke around a bit, but that's mainly superstition; if we were really afraid that something could be broken without us knowing, that would be a sign we hadn't written very good tests.
This means you want to cause the minimal amount of change to the codebase possible. [...] With maintenance you don't EVER want to refactor- refactoring has a much higher likelyhood of introducing bugs, requiring more extensive and expensive regression testing. You want to design the change, apply it, and then never touch that part again if possible.
This is only true if changing things is likely to introduce bugs. If regression testing is automated, it's cheap. And if you have full test suites and do pair programming, you are unlikely to introduce bugs. (At my current shop, we have bug rates well below one per developer/month.) That means that there's no reason not to refactor if the code needs it.
And there's a big reason to refactor. Your approach of fearfully making localized changes to the code without refactoring means that the broad design gets more and more distorted. Over time, the system gets squirrely enough that nobody really understands it, which increases the cost of change and increases risk. Eventually, your approach leads to the abandonment of the code base and a big fresh start. That's very expensive.
Extreme Programming, on the other hand, is designed to be sustainable over the long haul. Instead of assuming that the code base will eventually become moribund, XP tries to answer the question, "How can we keep this code good enough to work on forever, no matter how many changes are requested?"
They'll pump out more code than you're slowbie QA people can handle.
Hooray! That's what I want: people pumping out code.
I think you should next take your theory to Boeing; they'll be excited to hear a cheap way to get their workers to rivet more metal onto planes. And I'm sure the customers will be excited when they hear that the cost per pound of their planes will go down a lot.
Indeed, throughout my career I have noticed that projects usually have failed for reasons *other* than the methodology/approach being used.
This strikes me as a sign that the methodology in question is incomplete.
That's not to say that a methodology should be completely idiot-proof. But it should be possible for humans to do. It shouldn't solve all their problems, but the methodology should make the problems obvious as soon as possible, and give a good framework for thinking about solving them.
For me these days, the essential ingredient of any method for building software is tight feedback loops. If a method allows you four years between making guesses and finding out whether they're right, it's a method I'm content to let others try.
One finally interesting area is maintenance. It probably accounts for more than 80% of the development resources, yet I have never seen any formal method/strategy/tool for handling maintenance/change requests/bugfixes. Is this because maintenance is unsexy?
Extreme Programming qualifies. The way they look at it, after the first iteration is complete you're in maintenance mode. A steady stream of change requests come in, and every week you do the most important week's worth.
This is a good way to look at things, because it prevents you from shortchanging things that are important but not urgent. In Extreme Programming, there is no magic date when the project is "done", so there's no excuse for letting things get messy.
"You don't even bother doing a cost benefit analysis to compare a $500,000 machine to worker who earns 70 cents a day."
You might not. Some managers might not. But smart people go beyond simple labels.
Educated workers are much more productive and can do work of much higher quality. If the above comparison were the only thing that mattered, nothing would be manufactured in the US. But all the brute labor in China won't replace a semiconductor fab.
He also explained that the 70 cents a day was a NAFTA wage cap and the coompany had to provide free food and shelter to its employees because they couldn't live on the maximum salary they were legally allowed to have.
Once you find me a reference on a "NAFTA wage cap", I'll cease to roll my eyes at this. I've heard of nothing in NAFTA that imposes a salary cap, and the Mexican minimum wage is many times higher than that, and the median wage higher still.
That's not a slam against Indians (or other off-shoring cultures), but more a fact of life. They are disconnected from the project to such a degree that they have no real grasp of it other than to produce *exactly* what the specs document says. This is the same type of problem you see in using consulting firms like Anderson, nay, Accenture in developing your software.
Agreed! Personally, I'm not planning on getting out of the industry, but I do plan to work only on projects using agile methods like Extreme Programming. Why? Because methods like XP tightly integrate the businesspeople and the techies in a way that is impossible if you're working in different time zones.
Not only is this more efficient than a document-driven process, but it's so much more flexible that you can keep ahead of your competitors using traditional processes. For projects that need speed and flexibility, outsourcers can't compete, whether they're in an Accenture office or in Bangalore.
Are you serious about auto jobs? Have you seen Detroit or Flint Michigan? Auto jobs, by and large, ARE gone!
The Detroit car companies did get their asses kicked, but that doesn't prove much about offshoring. You have to add back in all the jobs that foreign car manufacturers have created in the US. And you can't count the jobs lost to technological improvement; automotive companies invest heavily in technology that reduces their labor costs, which often means a loss of jobs.
I'm curious as the actual cost of outsourcing.
I did some consulting for a large, software-focused company that has been trying some outsourcing. The have a standard company measure for units of functionality, and tried sending some projects to Indian programmers and measuring the cost. All things accounted for, the cost per unit was about 50% lower, not the radical 80-90% off that you hear.
But that didn't mean that they were going to do a lot of outsourcing. For the core parts of their software, they wanted in-house people to work on it; it's too risky putting the crown jewels in the hands of hired mercenaries. And the barriers to communication were large enough that many kinds of projects couldn't really be sent, because transferring the appropriate knowledge is too hard.
I automagically create the movies each day and throw them up on my website (I don't have enough bandwidth to actually give a link.)
Put up a link to a torrent! Then you can throttle the bandwidth at something pretty low and let the downloaders take up the burden.
People with ringtones on in theaters is a social problem. Social problems cannot be solved by technical means.
That's a reasonable heuristic, but it's foolish to state it as a general law and then make deductions from it. Theft is a social problem, but very few people bother stealing from vending machines these days because the anti-theft technology makes it so hard.
And really, I don't think this is a social problem. The main problem here is not that people are trying to be jerks, it's that they forget to turn off their phones and may thoughtlessly and reflexively answer them when they ring.
Even if you jam cellphones, they're still going to be talking loudly, or having some kid playing his gameboy, or crying, or throwing popcorn, or whatever. It won't solve anything.
Good theory. Alas, my data doesn't support it. The last three times this happened to me, it was in the middle of the movie and the culprit had been quiet up until then and was apologetic afterwards. So although jamming might not, technically, solve anything, it would improve things a fair bit.
What they should do is take the money they were going to use for this, hire a couple of bouncers[...]. End of story.
Ok, figure it costs $5k per theater to set this up. How long can you pay a bouncer per theater on that money? I make it less than half a year before you let the bouncers go. What do you plan to do then?
What's your excuse for getting spam?
How about the eight years of business cards I've handed out with the same address? Or the long-lost college pals who get in touch via the email address I still have after thirteen years? Or perhaps it's just a stubborn refusal to yield a medium I've spent twenty years using to a handful of greedy sociopaths.
Let's turn it around: What's your excuse for giving in to them?
In particular, programming methodologies such as Extreme Programming that require greater management involvement in the coding process will be treated with scorn; management wants less involvement, not more. As to whether or not the code actually works - once it's out the door and bonuses are in hand, who cares?
Well, for one, companies that want to make money. A company may be able to get away with shipping crap for a little while, but it's rare that somebody can do it for long. Why? It's not just that customers notice. A cruddy code base is hard to build on, so low initial quality means slow development for the life of the code base.
Once a manager has experienced doing a project right, it's pretty rare they want to go back to the old, painful, unproductive way of doing things.
Some of us more experienced developers do not think it is the holy grail. It looks like you can make as much mistake as in convetional languages. Also, development with a GUI (see at www.kc.com) is much more cumbersome.
Personally, I think this is akin to VRML: it's an idea that seems simple and obvious but will turn out to be a huge waste of time and money.
I think that tools that help you visualize things are great, but I think the way to greater productivity is through the kind of automation provided by modern editors like IntelliJ IDEA. It may be that one day somebody will develop a visual programming environment that lets you be as productive as code, but I think it will take a radically different programming language and a different physical user interface. For now I think it makes as much sense as an all-visual version of Microsoft Word for novelists.
The most effective techniques for finding defects is still code review. It seems that one of the pair programming is a very good way of doing code review.
Strongly agreed. Code reviews can be nice, but frequently the good suggestions come too late to be worth implementing. Pair programming gets you the feedback you need before you've gone too far down the wrong path.
Do NOT get the engineer who wrote the code to also write the test. It's fairly fundamental - the engineer who wrote it will have a prejudiced view of what should/will work. Get someone else to do it and get a valuable fresh insight.
You're acting as if it's either/or. The proper answer is both.
Unit tests verify that the code does what the programmer says it should. If the programmer does test-driven development, the engineer is much less likely to do the kind of shoddy testing you're worried about. The problem is further lessened if you do pair programming.
But I also think it's important to have tests written by other people, ones written from the perspective of the people who say what the requirements are. Those not only verify that the system works, but that the engineers built the right system.
The great thing about unit tests is that programmers can adopt them on their own. There's no need for separate QA, managerial approval, extra meetings, or anything like that. You can just write them because it makes your work easier. And boy howdy, it does.
But write which tests first? There are so many possible. Usually there are more ways for something to malfunction than for it to function correctly.
You write a test first. Then you make it pass. Which test? Whichever the most important one is.
We don't like the way that works in practice", you haven't wasted time writing 10 tests. Whereas if you do it the other way round, they can only find out they don't like it after you've written the 10 tests AND the actual code.
This would imply that writing the test slows things down. In my experience, and that of most other people who do test-driven development, having tests speeds things up because you spend less time debugging.
Doing the tests first also helps make sure you're doing the right thing. Writing a test case requires you to be more clear about what you're doing, so that you are forced to clarify the requirements before you write the code.
Your suggestion probably works well for certain scenarios, but appears counterproductive for many others.
That's a plausible theory. But having tried it both ways, I think it's incorrect. The only real way for you to find out is to try it yourself. Pick up Kent Beck's Test-Driven Development: By Example and give it a go.
If you write some code that reads several rows from a database and as a result writes a bunch of rows in another table, you need to run scripts before and after your unittest.
When something is hard to do, one option is to try a different way of doing this.
In the case of database interaction, mocking things out is a good step. A unit test might only verify that your code produces the proper SQL and interprets mock ResultSet objects properly; it need not talk to a real database.
Also, you probably shouldn't be scattering SQL everywhere throughout your app. If you isolate the SQL to a mapping layer, it's pretty easy to test that the mapping layer works with the database; then all the rest of the unit tests can use a mock database interface. Not only is that easier to test, but it's much, much faster.
It's of course all doable, it's just that it's sometimes more work than writing the method itself.
True, but irrelevant. The time to compare it to is not just the amount of time it takes to write the code, but also the amount of time you spend debugging that code over its lifetime. I do test-driven development in an XP shop. Our bug rates in production are lower than one per developer-month, and I spend perhaps 10 minutes a week using the debugger.
In my experience, the time and stress saved by doing extensive testing is well worth the time we spend writing tests. As a bonus, we spend little time writing documentation; if you want to know what some object is supposed to do, the unit tests make it pretty clear.
But I've come to realize, it [unit testing] just doesn't help to reduce big errors in system level design.
That's like saying that street maps don't tell you what the continent looks like. It's technically true, but it seems to miss the point.
Unit tests are for testing relatively small chunks of work. If you want to be sure the pieces work together, you do testing at higher levels. I think both are necessary for a solid system.
Personally, I think of my high-level tests as executable requirements. Every time I check in code, a server makes sure that all our tests, both unit and end-to-end, run happily. That's a big step up from the traditional requirements phone book that most people don't use except as an aid to yelling at someone.
I don't want to spend the rest of my life using my skills to make someone else money.
.NET, they don't want to hear about technical merits. They want to know which has lower development costs, which is easier for new employees to learn, how the choice affects maintenance costs, and generally what impact the choice has on their bottom line.
I'm sorry to say it, but this attitude alone disqualifies you from running your own business yet.
As a contractor or a consultant, you have to figure out how you can make other people money. That's the whole point of it; if they're not going to make a lot more money through your efforts than what you're charging, then they'd be fools to hire you, wouldn't they?
As an independent, you will spend a lot of time selling yourself. And unless you are able to seek out and clearly explain the benefits of win/win situations, you will have a terrible time of it. And even once the sale is made, you'll always need to explain things in business terms. When they have to choose between, say, Java or
So I'd say that you should just go out and get a regular job while you learn more about how the business world works. The best choice might be to start with some small contract development shop, somewhere you can have regular contact with the partners. Alternatively, consider working for a while on the other side of the fence, doing something where you help manage the purchase of technology services. Either one would be a good environment to see what it takes to succeed once you go on your own.
OTOH, you will never hear the FedGov call a voter/taxpayer what they really need to be called: a dumbass.
Honestly, I think the government should be willing to call more people dumbasses.
But if you're in business, it's hard to make the argument that it's ok to write X% of your customers off as fuckwits, especially if doing so may lead to people getting killed. The challenge when making any consumer product is to make it idiot-proof but still appealing to people who aren't dolts.
Of course, it's fun for smart people to yuck it up about dumb people, just as it's fun for the socially skilled to laugh at the dorky ways of the average Slashdotter. But when you're building things for consumers, I don't think there's much place for that attitude.
Show me a car that can't stop from any speed in under two minutes and I'll show you an engineer or two in the unemployment line.
Perhaps you were in a hurry and didn't have time to read all of his post. He's talking about with the throttle stuck open. If you think you can do it in under two minutes, I encourage you to upload the video of you trying.
I search for the book, go to the first page. I then download/save the next two pages. Then, I search for a line of text on the second page, go to that page, and then have the NEXT two pages available to me. If I keep doing this, I can read the entire book, although it may take a while.
Until somebody actually does this successfully, I'll remain skeptical that it will work. And anybody who is this lame strikes me as unlikely to buy the book anyhow, so it seems like there's no big loss.
major publishers to prove to Amazon and themselves that it actually eats sales rather than driving them -- the consensus of the publishing industry.
This is potentially true for books where a small snippet will do. Of course, that's exactly the kind of information that the Internet is already making available for free. There are already a zillion recipes on line, there's lots of technical information, and Wikipedia proves that it can be done for any sort of quick-and-easy reference.
On the other hand, I think it helps a lot of other books. Anything where you need a linear flow or large chunks of text, including all fiction and most non-fiction published today, doesn't seem vulnerable to attack-via-quick-peek. As others point out, for those it serves the same purpose that leafing through at the bookstore does. I can point to several books on my shelf that I only bought because I could preview it on line, including a couple from new authors that I otherwise wouldn't have touched.
It would have died a long time ago except that it is the pet project of someone high up in Amazon.
Oh, you mean like the customers?
A quick tip for your publishing pals: trying to stuff the digital genie back in the bottle won't work. Like it or not, the Internet is changing the economics of producing and selling information in ways both obvious and subtle. Innovating is great. Rolling with it is good. Mulishly resisting it is ridiculous.
Remember what the Japanese auto manufacturers did to the car industry, and how stubbornly the US carmakers tried to stick with old methods? You can see where it got them. And the Japanese just figured out how do things a bit more smoothly and efficiently. That's nothing compared to the potential of the Internet's impact on any digitizable commodity.