This is a bit like goofing off on the basis that you'll think better after 20 minutes of fooseball. I'd definitely subscribe to that theory, but many others may not.
The analogy I usually draw is to cooking.
Everybody's thrown a big dinner party and then left the dishes for a few days. Or even worse, had a roommate who did. Turns out this sucks, because if you just want to make yourself a little breakfast, then it's harder to cook. You have to scrape out a pan and chip off a plate just to get started. And cooking is twice as much work because you have to shift the mess around just to get at the counter, and then shift it again to get at the stove.
Then when you're done, you sure aren't going to wash up properly; the sink's filled with dishes already. So you just toss your dishes on the top of the pile, saying you'll get to it "later". Of course, that ever-growing mound of fuzzy dishes is the real-world analogy of half the code bases I've seen. And the giant rewrites that inevitably follow are like tearing down your kitchen and building a new one because that's the cheapest way out of the mess.
Instead, good chefs work clean. They clean as they go. Always. Not because they're uptight freaks, but because if they don't, the mess slows them down and makes them sloppier, eventually resulting in a giant clusterfuck, with all their colleagues yelling at them.
Refactoring is just a way for programmers to clean as they go. I picked up the habit years ago, and now would never go back, as it's the fastest way I've found to get good work done.
There is one important rule in creating a GUI: follow the same design principles as the target OS and applications with similar functionality as yours.
If there are 20 important rules, that might be one of them. But if you're going to pick exactly one, it has to be:
Test all your GUI choices with real users and revise based on those observations.
The essence of any good design is that it works for your chosen audience. The only way you will know if your design works is to have audience members try it. All the other design rules -- including yours -- are derived from lessons learned in that feedback loop.
I cannot count how many times I have heard this advice, yet it bears out repeating over and over and over again - do not sign ANYTHING without reading it first. This is the person's mistake, and he willingly admits to his mistake. It is a shame that it happened at an Apple store, but to be honest, it could have been anywhere, even an automotive repair shop.
People should read the stuff, sure. It can be informative. But that's not what's in play here.
The tiny pale-gray print on the back of a form is what it will come down to when you end up in a court of law. If you think some transaction might end up in court, then you should not only read the contract, you should get a lawyer specializing in that area of law to read it carefully and translate it for you. Amateur contract lawyers are worth approximately what you pay them.
But for these simple transactions, you don't need a lawyer, because you will just say "fuck it" before you spend the money on going to court. Instead what's going on here is about a company's brand reputation, which is mostly built and destroyed outside the realm of litigation.
If some company screws you over in some consumer deal, you go to the BBB, the state attorney general, your local consumer reporter, consumer-focused blogs, and other areas where you can make a big noise. But first, you politely threaten to go there to successively higher levels of management. up to and including the board of directors.
Requirement. Customers have the right to receive back all parts replaced, except those that must be returned to a supplier or manufacturer for warranty or rebuilding purposes, which the customer is entitled to inspect (MCL 257.1333).
This seems like one of those duh-so-obvious consumer protection laws, as well as good business practice for anybody trying to appear on the up and up. Doesn't every state do this?
I don't blame anyone, even government in this case, for avoiding the hassle of getting everything converted to IPv6.
You're right that it's all about hassle avoidance.
A pal of mine in government called me up in 1998 because some department was refusing to change a network-based app until after the IPv6 transition was complete. Not because it needed any of the IPv6 features or anything. They just claimed that since it was an IP-based app, it would be better to wait for the new protocol version to come out.
Wait, that's not even hassle avoidance. It's just work avoidance. Sigh.
[...] I absolutely hate going through other people's code in java, especially in a J2EE stack where you've got a class structure 15 layers deep
No argument here. When I find that crap, I rip it out. But I think that pathological code in any language should just be thrown out and rebuilt. I was more thinking of non-worthless code bases.
For those, I think Java's strict, static typing makes it relatively easy to run down mysteries when you compare it with, say, somebody redefining the Ruby methods on Array and String. Or doing run-time code generation, a popular Ruby trick that makes me all stabby.
Now that I think about it, though, my main preference is not to take on scruffy code bases at all. Here's to hoping that when this tech bubble pops, it's gentle enough that we can all avoid that kind of work.
But I must also point out that for every example you can give with a success story like Flickr, there are 99 abject failures that show how difficult it is to be flexible this way, it demands discipline. Maybe it is even so that the more flexible and agile you are the more discipline you need to have.
I agree completely. Without smart, experienced people with the discipline to envision a process, follow it, and adjust as needed, I think any project is screwed.
The thing that kills me about a lot of the formal, high-ceremony, high-documentation methods out there is that they are sold as something to do instead of getting great people and being disciplined. Many people cater to the dumb manager's desire to believe that if they only follow some magic recipe, great software comes out at the end no matter how screwed up your organization is.
Not that some agile process proponents don't also over-promote, but the Agile Manifesto makes it clear that process isn't the answer, which does help limit the damage.:-)
It costs more. And here I mean expressive duplication. It's bad for exactly the same reason that copy-paste coding is bad. System redundancy is fine, but you can do that without expressive duplication.
You seem to be describing an XP environment... XP is known to be an unstable methodology, both in theory and practice.
I don't think of what I'm doing as XP exactly, but that's close enough. Still, it's working well for me and my teams. Come to Agile 2008 and you'll find plenty of other people that the practices are working well for.
And by "working well" I mainly mean happy staff, happy managers, on-time delivery, and unbelievably low bug rates. One project we did 6 years ago has been running with no downtime since then, and somebody just found the third bug in production. Recent projects have also been below one bug per developer-month, and often well below. My view: if you make so many bugs you need a database to track them, you're doing something wrong.
Usually someone sits back and watches the other one code, going, "huh?" until they either give up and do something else or have to switch.
That's not pair programming, then. Control should change hands every 5-15 minutes. Both people should have equal access to keyboard, mouse, and screen. Both people should feel engaged. When you ask them the next day, "Who wrote this method?" the answer should be, "We did."
(story cards be damned; formal initial design and modeling are important!)
Story cards work fine for me with collocated teams. That doesn't mean I don't do initial design. I just don't hold up the show for it, or take my initial designs very seriously. The more information you have to feed your designs, the better they will be. And the beginning of the project is when you have the least information. Therefore, all design decisions should be made at the last responsible moment.
One of my teams began doing a web startup in December. They have been doing weekly iterations since then, with releases every couple of days since February. They're now coming up on 2 million visitors a month, and just recently made some of the architectural choices around multi-machine distribution. There was no need to make them sooner, and now they know exactly what they need to do. Easy peasy.
Heck, the flagship XP project at Daimler Chrysler floundered until the day it was decommissioned, even with the big XP cheeses at the helm.
From my understanding, this was a political and business issue, not one with the team's output. They made a payroll system that worked. Regardless, we have learned a lot in the last decade about how to make agile methods work, so judging current efforts by ancient history seems a little unfair.
Except when you have a function that's not called anywhere except from its unit test... then if you delete the function the unit test fails! You have to delete the test AND the function and then suddenly you have the same situation of fear of removing two things instead of one.
Tests are executable requirements. You should be careful when changing requirements. Fear seems excessive, though.
If it's only a unit test that fails, then it's a software design question. If I was unsure about keeping the method, I'd ask the team. If both acceptance and unit tests fail, then I'd ask the product manager (who is sitting right there) if they still cared about that requirement.
Generally, though, I don't need to ask, because I look at the failing test and say, "Oh, right. That's what this is for."
From what I've seen, fear of changing the code is almost always an indicator that the team doesn't trust the tests. Fix that problem first.
In what other line of work does principal construction begin before the customer has defined what it is they are ordering?
One place is in art. Especially collaborative art, like plays and movies. For serial TV shows, it is impossible to define it up front. And for improvisational theater, by definition you don't define it.
See the great book Artful Making if you'd like to learn more about that kind of work, and why modern knowledge work is much more like that than the industrial approach you're following.
Changing to a structured approach to working is costly, but the benifits are bountiful [...]
This is plausible in very specific problem domains where people a) know what they want, and b) what they want won't change. But it is fundamentally impossible in domains that are poorly understood or continuously shifting. It is also impossible if your product development process uses user feedback for planning. All three of these characteristics apply to a lot of web startups.
Take Flickr as an example. In under two years, they went from a side project to a $20m sale. (If they had held out until now, they could have been a $100m sale.) Their initial ideas were ok, but not great. But they released early and often, pushing to production every few hours. And then they listened to their users intently, continuously improving Flickr's fit to their audience's need. That relationship is only possible with an agile approach.
And before people jump on me about anecdotes versus data, I'll point at a VC's look back on companies he funded. Two thirds of his winners significantly reinvented their businesses between funding and success. That's not to say you have to use an agile approach for that. But agile methods are much cheaper in changing circumstances than structured ones, so you'll have to have much deeper pockets to survive.
And just to be clear, I'm not talking about the chaos of code n' fix here. I'm talking about highly disciplined agile methods, where you include practices like test-driven development, acceptance testing, pair programming, collocated teams, in-room product management, aggressive refactoring, short iterations (like a week), and frequent releases (daily to monthly, no more).
I think we agree pretty much completely on the spirit of things, and were we coding together, I'm sure we'd get along well. However, I think you got the bit about agile teams wrong.
I've met people of the agile variety who insist that well-written code needs no documentation: that if you carve your code up into small, tight, appropriately named classes and methods it becomes obvious what your code does and your code becomes "self-documenting", [...] it's still a challenge to see the forest for the trees [...] it also means that after several refactors you end up with a whole lot of miniature orphaned functions littering up your code that are never called and that do nothing but that everyone's afraid of deleting)
I'm not sure if you're dealing with idiots who are skipping practices or if you just missed the bigger picture, but either way let me explain how that approach can work very well.
For an agile team coding like that, I'd expect them to be doing test-driven development, working in a team room, doing pair programming, and swapping pairs every few hours.
In those conditions, the bigger picture lives in everybody's heads. You don't write it down because it would be pure waste. The time to document it is when team continuity might be broken. Like when you put a project aside for a while, transfer it to another team, or publish an API. Then you schedule the writing of documentation in the queue with all the other work. That should certainly include a big-picture explanation of the system.
If you've got good unit test coverage, nobody should be afraid of deleting anything. If the tests fail, you just hit undo. And if you've got good acceptance test coverage, most languages have tools that will let you check for unexecuted code. When I'm working in Java, I use IntelliJ's IDEA, which automatically highlights unreachable or unreached code, which I love.
Those tests also shouldn't be mere tests. They should be an explanation of what something is for, built around examples that computers can verify. For the developer side, check out the various Behavior-Driven Development frameworks that have appeared in the last couple of years. For the acceptance tests, see FIT, FITnesse, and other tools that are focused not just on testing but on explaining the product.
The reason Agile people lean away from documentation by default is that documentation is by definition redundant. It's extra work to write, it adds a tax on changing the thing it documents, and it risks drifting out of date. Instead put a lot of effort into making the primary artifacts communicate well (via clear code; great names for variables, methods, and classes; well organized file layouts; clean system architectures; readable tests; and everything else that makes up beautiful code). Every time I get the urge to document something, I first try to make it clearer, so the documentation isn't necessary. When I can't, I document.
Is that specifically because of the 35 hour week or because of overall bureaucracy?
Overall bureaucracy was my impression.
Personal anecdotes aside, there's no clear proof of a negative impact on employment (though also no positive effect.
I presume you're talking about the shortened work week, rather than the bureaucracy in general. Of course, given that it was supposed to help unemployment, that it doesn't help suggests that it should be repealed and replaced with something else.
That sounds good in theory. However without government interfering the individual employee has far too little bargaining power. [...] The only alternative is collective bargaining, which once again means no individual choice.
It depends on the size of your collective and the size of the employer, and also on the nature of the work.
One person threatening to quit can mean a big deal to a five-person company, especially if they're a heavy hitter. For a company of five thousand, not so much. But negotiating collectives can be large enough to negotiate effectively without being large enough to prevent employee choice entirely.
Aside from making collectives bigger, one could make companies smaller. Technology has made it orders of magnitude easier to run a small company these days. A good portion of the large companies I've seen are fed more by power to bully and cheat, rather than the typical justification, economy of scale. Perhaps a progressive tax based on company size would be more effective at improving employee negotiating power than a one-size-fits-all solution.
And for a fair number of people, I don't think they need government help. As the value of knowledge and skill increases relative to capital, employers have a much bigger incentive to keep people happy. See this article on SAS, for example. For them, the government-mandated work week is purely a hindrance.
Ahhh, but therein lies the problem, lack of proper education, and yet we keep paying teachers more, even though all they do is teach obedience in schools, and listening to authority.
First, as others have told you, teachers are far from overpaid given the work.
More importantly, you contradict yourself. Every teacher I know would love to give a more personal, independence-focused education to their students. But they have to teach obedience because that's the only way for anybody to learn anything with current student-teacher ratios.
People already know how to educate for independence. It's just that it costs a lot more. You want it? Go lead a charge for a tax increase that would get us 3-4x the number of teachers we have today.
And it'll be easier if you start showing teachers some respect. I know one daughter of Korean immigrants who was forbidden to become a teacher because they thought Americans didn't appreciate educators.
But for teams over 3-4 people I think I'd rather use Java.
I feel the same way. For small projects, I love dynamic languages like Ruby. In Java, you have to be painfully explicit, whereas RoR has a lot of excellent magic, and things practically happen on their own.
The problem with magic, though, is that it's magical. When I'm the wizard, that's fabulous. When I'm trying to get my head around the code of somebody who isn't here anymore, RoR is not so good for that. Suddenly, Java's annoying redundancy and its demand you keep stating the obvious comes in handy, as you can actually tug on something and find what it is connected to.
If you do most of the logic in your stored procedures, it makes it easy to bolt on new features written in various languages. If you decide to have a perl script for a cron job, you just call the same stored procedures your ruby app is calling. [...] Once you bury the database logic in the application code, you have to rewrite it for every application. It is, in a way, a very evil form of copy & paste programming.
That's a good point, but I think you're learning the wrong lesson from it.
Yes, duplicating your database schemas across multiple code bases is bad, as it makes it approximately impossible to update things. But pushing all the brains into your database leaves you with four problems. One, you're generally locked into exactly one vendor. Two, the variety and quality of development tools is poorer. Three, if there's some other storage technology you want to use, you're generally screwed. And four, your various code bases are still tied to specific stored-procedure calls, which last I looked didn't have much in the way of protocol versioning.
I think the better option is to follow the OO approach, where you keep behavior and data together. You make yourself a tidy service layer in some convenient protocol like RESTful HTTP with XML or JSON. (Rails has nice support for that, BTW.) Give it a little versioning, so that you can transparently extend your APIs. That gives you the same kind of isolation your stored procedures do, but a much wider range of tools for both client- and server-side development.
In my view, that gives you the same clean boundary and exactly one code base mucking with raw data, but a lot more flexibility over the long haul.
Getting a *PROGRAMMER'S* opinion on data modeling is probably not a good idea. [...] No, the database is the foundation of the business. It should be properly designed.
Over the years I have developed a simple rule.
In every profession, there are people who say, "No, MY specialty is the TRULY IMPORTANT ONE, and it MUST be in charge." I have heard this from programmers, DBAs, project managers, "architects", product managers, graphic designers, UI designers, business analysts, process consultants, engineering managers, and executives of every stripe. (I think the only people I haven't heard it from are the secretaries and administrative assistants. Probably because they know they are already in charge.)
My simple rule: anybody who says their specialty must be in charge has instantly disqualified themselves from being in charge.
That's not to say that those people, yourself included, are useless. They can be excellent, within the bounds of their specialty. It's just that they (and sorry, you) have too narrow a view of what's going on.
I mainly agree with you here, and share your annoyance with the stats-bending grumpmeister you were replying to. One comment on this, though:
I quite fail to see how a 35 hour workweek or 6 weeks of paid leave [...] are bad things.
I think there's nothing wrong with those things. I think a government requirement for it is generally a bad idea.
For example, I know a Frenchman who lived in the US for a while and started a business there. He now lives in Paris and loves it, but all of his staff are still in the US. When I asked him when he was going to hire people in France, he said never. Why? Too much hassle. Even if he couldn't hire in the US, the extensive regulations would still make him very resistant to hiring European staff. Unemployment in action.
We're all trading free time for money, and I think it's better to let people decide the right balance individually. And the reason most politicians promote a reduced-work-week scheme is a fallacy, the lump-of-labor fallacy.
People these days just can't accept personal responsibility for things; it's ridiculous.
Choosing not to use credit cards sounds pretty responsible to me. Not only is it fiscally responsible, but he knows his limits and is sticking to them. What's not to like about that?
But for how long? I think Fascism is unstable on the scale of decades as long as trade is free and easy.
Modern economies depend on economic growth. If the elite capture all of that, you end up with terrible social stresses from the inequality, and you limit growth through lack of consumers and limited productivity. If you distribute the gains more widely, lots of people end up with luxuries like education, time to think, and the belief that the elite is no better than they are.
Once you have a comfortable middle class, I think it's hard to avoid ending up with democracy. South Korea could have been called Fascist during their period of military dictatorship, but they've turned out pretty well. I expect China will go the same route as the gerontocracy dies off.
okay, what if you're in $PUBLIC_PLACE, and your mother calls telling you that your father had a heart attack?
I pretty regularly run across public places where my cellphone doesn't work. In large buildings, in hilly areas, and places where I've switched off my cellphone to be polite. Why wouldn't I be able to cope with one more?
But while it's interesting from a neuroscience point of view to discover the location of these experiences within the brain, it doesn't give us any philosophical insight into the existence or non-existence of God. [...] So: philosophically uninteresting.
Not so. It doesn't tell us anything directly about the existence of God. But it does indirectly, as it tells us something about the existence of religion.
One reasonable question to ask of atheists is: "If there's no God, then why is almost everybody religious?" Currently, there isn't a great answer to that question. A lot of people take that as proof that there has to be something to all this religion. Yes, that's the same broken logic behind the, "there must be a pony somewhere in this pile of horseshit" joke. Like it or not, though, people take the absence of an answer as its own kind of answer.
But this "God helmet" thing is one piece of the puzzle. With enough of those pieces, we can put together a decently scientific answer. It'll be something like, "Because of particular quirks of the human brain, people are predisposed to believe certain irrational things, including religion." We're probably a generation off from having the core of that answer, and two generations from having the details filled in.
It's like the theory of evolution. It doesn't tell us anything about the existence of God. But theists attack evolution because it answers a question that drives people to religion. They'll attack this upcoming theory, too, for exactly the same reason.
I tolerate my neighbor playing his stereo too loud sometimes. In particular, I don't verbally abuse him, tell him that God hates him, have stereo-playing ruled illegal, have cops bust into places where people play stereos too loud, assault him for indicating his preference for loud music, tell him he can't get married when he finds some partner who likes his same lame music, or consider it reasonable for him to be beaten to death by people suffering from "stereo panic".
I don't love him for it. I don't accept it. I put up with it, because he's my neighbor and that's what he likes doing and in the end it's his life. It is not my right to accept or not accept his behavior. Just like, according to Jesus, it was not the right of that mob to stone the adulterers to death. That's tolerance.
You're about as likely to die from a weekend party pill as you are from your contraceptive pill.
And that turns out to be much safer than skydiving, which seems to weigh in around one death per 100,000 jumps. Funny that the more dangerous one is legal.
Personally, I propose the same solution for both: mandatory licensing. If you want to take MDMA or jump out of planes, you just have to do the six-week course with practical exam at the end.
Slashdot Mirror
I agree that this is a terrible analogy:
This is a bit like goofing off on the basis that you'll think better after 20 minutes of fooseball. I'd definitely subscribe to that theory, but many others may not.
The analogy I usually draw is to cooking.
Everybody's thrown a big dinner party and then left the dishes for a few days. Or even worse, had a roommate who did. Turns out this sucks, because if you just want to make yourself a little breakfast, then it's harder to cook. You have to scrape out a pan and chip off a plate just to get started. And cooking is twice as much work because you have to shift the mess around just to get at the counter, and then shift it again to get at the stove.
Then when you're done, you sure aren't going to wash up properly; the sink's filled with dishes already. So you just toss your dishes on the top of the pile, saying you'll get to it "later". Of course, that ever-growing mound of fuzzy dishes is the real-world analogy of half the code bases I've seen. And the giant rewrites that inevitably follow are like tearing down your kitchen and building a new one because that's the cheapest way out of the mess.
Instead, good chefs work clean. They clean as they go. Always. Not because they're uptight freaks, but because if they don't, the mess slows them down and makes them sloppier, eventually resulting in a giant clusterfuck, with all their colleagues yelling at them.
Refactoring is just a way for programmers to clean as they go. I picked up the habit years ago, and now would never go back, as it's the fastest way I've found to get good work done.
If there are 20 important rules, that might be one of them. But if you're going to pick exactly one, it has to be:
The essence of any good design is that it works for your chosen audience. The only way you will know if your design works is to have audience members try it. All the other design rules -- including yours -- are derived from lessons learned in that feedback loop.
I cannot count how many times I have heard this advice, yet it bears out repeating over and over and over again - do not sign ANYTHING without reading it first. This is the person's mistake, and he willingly admits to his mistake. It is a shame that it happened at an Apple store, but to be honest, it could have been anywhere, even an automotive repair shop.
People should read the stuff, sure. It can be informative. But that's not what's in play here.
The tiny pale-gray print on the back of a form is what it will come down to when you end up in a court of law. If you think some transaction might end up in court, then you should not only read the contract, you should get a lawyer specializing in that area of law to read it carefully and translate it for you. Amateur contract lawyers are worth approximately what you pay them.
But for these simple transactions, you don't need a lawyer, because you will just say "fuck it" before you spend the money on going to court. Instead what's going on here is about a company's brand reputation, which is mostly built and destroyed outside the realm of litigation.
If some company screws you over in some consumer deal, you go to the BBB, the state attorney general, your local consumer reporter, consumer-focused blogs, and other areas where you can make a big noise. But first, you politely threaten to go there to successively higher levels of management. up to and including the board of directors.
Under Michigan law, yes:
This seems like one of those duh-so-obvious consumer protection laws, as well as good business practice for anybody trying to appear on the up and up. Doesn't every state do this?
Back in my day, all we got was a telnet client and a dns query tool
You had DNS? Luxury! Why back in my day, there was just one HOSTS file, and everybody shared it.
Oh, and Bitnet. We had Bitnet, too. Yes kids, way back when, there were competitors to the Internet.
Christ, I wish I were kidding. KA9Q represent, yo!
"(lock picking, dumpster diving, going through air vents/windows)" Funny, when I did that they called it B&E - sigh.
Take ten thousand dollars and your a thief. Take ten billion dollars and you're a dynamic new business leader.
I don't blame anyone, even government in this case, for avoiding the hassle of getting everything converted to IPv6.
You're right that it's all about hassle avoidance.
A pal of mine in government called me up in 1998 because some department was refusing to change a network-based app until after the IPv6 transition was complete. Not because it needed any of the IPv6 features or anything. They just claimed that since it was an IP-based app, it would be better to wait for the new protocol version to come out.
Wait, that's not even hassle avoidance. It's just work avoidance. Sigh.
[...] I absolutely hate going through other people's code in java, especially in a J2EE stack where you've got a class structure 15 layers deep
No argument here. When I find that crap, I rip it out. But I think that pathological code in any language should just be thrown out and rebuilt. I was more thinking of non-worthless code bases.
For those, I think Java's strict, static typing makes it relatively easy to run down mysteries when you compare it with, say, somebody redefining the Ruby methods on Array and String. Or doing run-time code generation, a popular Ruby trick that makes me all stabby.
Now that I think about it, though, my main preference is not to take on scruffy code bases at all. Here's to hoping that when this tech bubble pops, it's gentle enough that we can all avoid that kind of work.
But I must also point out that for every example you can give with a success story like Flickr, there are 99 abject failures that show how difficult it is to be flexible this way, it demands discipline. Maybe it is even so that the more flexible and agile you are the more discipline you need to have.
:-)
I agree completely. Without smart, experienced people with the discipline to envision a process, follow it, and adjust as needed, I think any project is screwed.
The thing that kills me about a lot of the formal, high-ceremony, high-documentation methods out there is that they are sold as something to do instead of getting great people and being disciplined. Many people cater to the dumb manager's desire to believe that if they only follow some magic recipe, great software comes out at the end no matter how screwed up your organization is.
Not that some agile process proponents don't also over-promote, but the Agile Manifesto makes it clear that process isn't the answer, which does help limit the damage.
And redundancy is a Bad Thing because?
It costs more. And here I mean expressive duplication. It's bad for exactly the same reason that copy-paste coding is bad. System redundancy is fine, but you can do that without expressive duplication.
You seem to be describing an XP environment... XP is known to be an unstable methodology, both in theory and practice.
I don't think of what I'm doing as XP exactly, but that's close enough. Still, it's working well for me and my teams. Come to Agile 2008 and you'll find plenty of other people that the practices are working well for.
And by "working well" I mainly mean happy staff, happy managers, on-time delivery, and unbelievably low bug rates. One project we did 6 years ago has been running with no downtime since then, and somebody just found the third bug in production. Recent projects have also been below one bug per developer-month, and often well below. My view: if you make so many bugs you need a database to track them, you're doing something wrong.
Usually someone sits back and watches the other one code, going, "huh?" until they either give up and do something else or have to switch.
That's not pair programming, then. Control should change hands every 5-15 minutes. Both people should have equal access to keyboard, mouse, and screen. Both people should feel engaged. When you ask them the next day, "Who wrote this method?" the answer should be, "We did."
(story cards be damned; formal initial design and modeling are important!)
Story cards work fine for me with collocated teams. That doesn't mean I don't do initial design. I just don't hold up the show for it, or take my initial designs very seriously. The more information you have to feed your designs, the better they will be. And the beginning of the project is when you have the least information. Therefore, all design decisions should be made at the last responsible moment.
One of my teams began doing a web startup in December. They have been doing weekly iterations since then, with releases every couple of days since February. They're now coming up on 2 million visitors a month, and just recently made some of the architectural choices around multi-machine distribution. There was no need to make them sooner, and now they know exactly what they need to do. Easy peasy.
Heck, the flagship XP project at Daimler Chrysler floundered until the day it was decommissioned, even with the big XP cheeses at the helm.
From my understanding, this was a political and business issue, not one with the team's output. They made a payroll system that worked. Regardless, we have learned a lot in the last decade about how to make agile methods work, so judging current efforts by ancient history seems a little unfair.
Except when you have a function that's not called anywhere except from its unit test... then if you delete the function the unit test fails! You have to delete the test AND the function and then suddenly you have the same situation of fear of removing two things instead of one.
Tests are executable requirements. You should be careful when changing requirements. Fear seems excessive, though.
If it's only a unit test that fails, then it's a software design question. If I was unsure about keeping the method, I'd ask the team. If both acceptance and unit tests fail, then I'd ask the product manager (who is sitting right there) if they still cared about that requirement.
Generally, though, I don't need to ask, because I look at the failing test and say, "Oh, right. That's what this is for."
From what I've seen, fear of changing the code is almost always an indicator that the team doesn't trust the tests. Fix that problem first.
In what other line of work does principal construction begin before the customer has defined what it is they are ordering?
One place is in art. Especially collaborative art, like plays and movies. For serial TV shows, it is impossible to define it up front. And for improvisational theater, by definition you don't define it.
See the great book Artful Making if you'd like to learn more about that kind of work, and why modern knowledge work is much more like that than the industrial approach you're following.
Changing to a structured approach to working is costly, but the benifits are bountiful [...]
This is plausible in very specific problem domains where people a) know what they want, and b) what they want won't change. But it is fundamentally impossible in domains that are poorly understood or continuously shifting. It is also impossible if your product development process uses user feedback for planning. All three of these characteristics apply to a lot of web startups.
Take Flickr as an example. In under two years, they went from a side project to a $20m sale. (If they had held out until now, they could have been a $100m sale.) Their initial ideas were ok, but not great. But they released early and often, pushing to production every few hours. And then they listened to their users intently, continuously improving Flickr's fit to their audience's need. That relationship is only possible with an agile approach.
And before people jump on me about anecdotes versus data, I'll point at a VC's look back on companies he funded. Two thirds of his winners significantly reinvented their businesses between funding and success. That's not to say you have to use an agile approach for that. But agile methods are much cheaper in changing circumstances than structured ones, so you'll have to have much deeper pockets to survive.
And just to be clear, I'm not talking about the chaos of code n' fix here. I'm talking about highly disciplined agile methods, where you include practices like test-driven development, acceptance testing, pair programming, collocated teams, in-room product management, aggressive refactoring, short iterations (like a week), and frequent releases (daily to monthly, no more).
I think we agree pretty much completely on the spirit of things, and were we coding together, I'm sure we'd get along well. However, I think you got the bit about agile teams wrong.
I've met people of the agile variety who insist that well-written code needs no documentation: that if you carve your code up into small, tight, appropriately named classes and methods it becomes obvious what your code does and your code becomes "self-documenting", [...] it's still a challenge to see the forest for the trees [...] it also means that after several refactors you end up with a whole lot of miniature orphaned functions littering up your code that are never called and that do nothing but that everyone's afraid of deleting)
I'm not sure if you're dealing with idiots who are skipping practices or if you just missed the bigger picture, but either way let me explain how that approach can work very well.
For an agile team coding like that, I'd expect them to be doing test-driven development, working in a team room, doing pair programming, and swapping pairs every few hours.
In those conditions, the bigger picture lives in everybody's heads. You don't write it down because it would be pure waste. The time to document it is when team continuity might be broken. Like when you put a project aside for a while, transfer it to another team, or publish an API. Then you schedule the writing of documentation in the queue with all the other work. That should certainly include a big-picture explanation of the system.
If you've got good unit test coverage, nobody should be afraid of deleting anything. If the tests fail, you just hit undo. And if you've got good acceptance test coverage, most languages have tools that will let you check for unexecuted code. When I'm working in Java, I use IntelliJ's IDEA, which automatically highlights unreachable or unreached code, which I love.
Those tests also shouldn't be mere tests. They should be an explanation of what something is for, built around examples that computers can verify. For the developer side, check out the various Behavior-Driven Development frameworks that have appeared in the last couple of years. For the acceptance tests, see FIT, FITnesse, and other tools that are focused not just on testing but on explaining the product.
The reason Agile people lean away from documentation by default is that documentation is by definition redundant. It's extra work to write, it adds a tax on changing the thing it documents, and it risks drifting out of date. Instead put a lot of effort into making the primary artifacts communicate well (via clear code; great names for variables, methods, and classes; well organized file layouts; clean system architectures; readable tests; and everything else that makes up beautiful code). Every time I get the urge to document something, I first try to make it clearer, so the documentation isn't necessary. When I can't, I document.
Is that specifically because of the 35 hour week or because of overall bureaucracy?
Overall bureaucracy was my impression.
Personal anecdotes aside, there's no clear proof of a negative impact on employment (though also no positive effect.
I presume you're talking about the shortened work week, rather than the bureaucracy in general. Of course, given that it was supposed to help unemployment, that it doesn't help suggests that it should be repealed and replaced with something else.
That sounds good in theory. However without government interfering the individual employee has far too little bargaining power. [...] The only alternative is collective bargaining, which once again means no individual choice.
It depends on the size of your collective and the size of the employer, and also on the nature of the work.
One person threatening to quit can mean a big deal to a five-person company, especially if they're a heavy hitter. For a company of five thousand, not so much. But negotiating collectives can be large enough to negotiate effectively without being large enough to prevent employee choice entirely.
Aside from making collectives bigger, one could make companies smaller. Technology has made it orders of magnitude easier to run a small company these days. A good portion of the large companies I've seen are fed more by power to bully and cheat, rather than the typical justification, economy of scale. Perhaps a progressive tax based on company size would be more effective at improving employee negotiating power than a one-size-fits-all solution.
And for a fair number of people, I don't think they need government help. As the value of knowledge and skill increases relative to capital, employers have a much bigger incentive to keep people happy. See this article on SAS, for example. For them, the government-mandated work week is purely a hindrance.
Ahhh, but therein lies the problem, lack of proper education, and yet we keep paying teachers more, even though all they do is teach obedience in schools, and listening to authority.
First, as others have told you, teachers are far from overpaid given the work.
More importantly, you contradict yourself. Every teacher I know would love to give a more personal, independence-focused education to their students. But they have to teach obedience because that's the only way for anybody to learn anything with current student-teacher ratios.
People already know how to educate for independence. It's just that it costs a lot more. You want it? Go lead a charge for a tax increase that would get us 3-4x the number of teachers we have today.
And it'll be easier if you start showing teachers some respect. I know one daughter of Korean immigrants who was forbidden to become a teacher because they thought Americans didn't appreciate educators.
But for teams over 3-4 people I think I'd rather use Java.
I feel the same way. For small projects, I love dynamic languages like Ruby. In Java, you have to be painfully explicit, whereas RoR has a lot of excellent magic, and things practically happen on their own.
The problem with magic, though, is that it's magical. When I'm the wizard, that's fabulous. When I'm trying to get my head around the code of somebody who isn't here anymore, RoR is not so good for that. Suddenly, Java's annoying redundancy and its demand you keep stating the obvious comes in handy, as you can actually tug on something and find what it is connected to.
If you do most of the logic in your stored procedures, it makes it easy to bolt on new features written in various languages. If you decide to have a perl script for a cron job, you just call the same stored procedures your ruby app is calling. [...] Once you bury the database logic in the application code, you have to rewrite it for every application. It is, in a way, a very evil form of copy & paste programming.
That's a good point, but I think you're learning the wrong lesson from it.
Yes, duplicating your database schemas across multiple code bases is bad, as it makes it approximately impossible to update things. But pushing all the brains into your database leaves you with four problems. One, you're generally locked into exactly one vendor. Two, the variety and quality of development tools is poorer. Three, if there's some other storage technology you want to use, you're generally screwed. And four, your various code bases are still tied to specific stored-procedure calls, which last I looked didn't have much in the way of protocol versioning.
I think the better option is to follow the OO approach, where you keep behavior and data together. You make yourself a tidy service layer in some convenient protocol like RESTful HTTP with XML or JSON. (Rails has nice support for that, BTW.) Give it a little versioning, so that you can transparently extend your APIs. That gives you the same kind of isolation your stored procedures do, but a much wider range of tools for both client- and server-side development.
In my view, that gives you the same clean boundary and exactly one code base mucking with raw data, but a lot more flexibility over the long haul.
Getting a *PROGRAMMER'S* opinion on data modeling is probably not a good idea. [...] No, the database is the foundation of the business. It should be properly designed.
Over the years I have developed a simple rule.
In every profession, there are people who say, "No, MY specialty is the TRULY IMPORTANT ONE, and it MUST be in charge." I have heard this from programmers, DBAs, project managers, "architects", product managers, graphic designers, UI designers, business analysts, process consultants, engineering managers, and executives of every stripe. (I think the only people I haven't heard it from are the secretaries and administrative assistants. Probably because they know they are already in charge.)
My simple rule: anybody who says their specialty must be in charge has instantly disqualified themselves from being in charge.
That's not to say that those people, yourself included, are useless. They can be excellent, within the bounds of their specialty. It's just that they (and sorry, you) have too narrow a view of what's going on.
I think there's nothing wrong with those things. I think a government requirement for it is generally a bad idea.
For example, I know a Frenchman who lived in the US for a while and started a business there. He now lives in Paris and loves it, but all of his staff are still in the US. When I asked him when he was going to hire people in France, he said never. Why? Too much hassle. Even if he couldn't hire in the US, the extensive regulations would still make him very resistant to hiring European staff. Unemployment in action.
We're all trading free time for money, and I think it's better to let people decide the right balance individually. And the reason most politicians promote a reduced-work-week scheme is a fallacy, the lump-of-labor fallacy.
People these days just can't accept personal responsibility for things; it's ridiculous.
Choosing not to use credit cards sounds pretty responsible to me. Not only is it fiscally responsible, but he knows his limits and is sticking to them. What's not to like about that?
China proves that Fascism, not Socialism, works.
But for how long? I think Fascism is unstable on the scale of decades as long as trade is free and easy.
Modern economies depend on economic growth. If the elite capture all of that, you end up with terrible social stresses from the inequality, and you limit growth through lack of consumers and limited productivity. If you distribute the gains more widely, lots of people end up with luxuries like education, time to think, and the belief that the elite is no better than they are.
Once you have a comfortable middle class, I think it's hard to avoid ending up with democracy. South Korea could have been called Fascist during their period of military dictatorship, but they've turned out pretty well. I expect China will go the same route as the gerontocracy dies off.
They actually have a bot that looks for copyright violations like that now. It's CorenSearchBot. So they're clearly taking it seriously.
okay, what if you're in $PUBLIC_PLACE, and your mother calls telling you that your father had a heart attack?
I pretty regularly run across public places where my cellphone doesn't work. In large buildings, in hilly areas, and places where I've switched off my cellphone to be polite. Why wouldn't I be able to cope with one more?
But while it's interesting from a neuroscience point of view to discover the location of these experiences within the brain, it doesn't give us any philosophical insight into the existence or non-existence of God. [...] So: philosophically uninteresting.
Not so. It doesn't tell us anything directly about the existence of God. But it does indirectly, as it tells us something about the existence of religion.
One reasonable question to ask of atheists is: "If there's no God, then why is almost everybody religious?" Currently, there isn't a great answer to that question. A lot of people take that as proof that there has to be something to all this religion. Yes, that's the same broken logic behind the, "there must be a pony somewhere in this pile of horseshit" joke. Like it or not, though, people take the absence of an answer as its own kind of answer.
But this "God helmet" thing is one piece of the puzzle. With enough of those pieces, we can put together a decently scientific answer. It'll be something like, "Because of particular quirks of the human brain, people are predisposed to believe certain irrational things, including religion." We're probably a generation off from having the core of that answer, and two generations from having the details filled in.
It's like the theory of evolution. It doesn't tell us anything about the existence of God. But theists attack evolution because it answers a question that drives people to religion. They'll attack this upcoming theory, too, for exactly the same reason.
You have conflated tolerance and acceptance.
I tolerate my neighbor playing his stereo too loud sometimes. In particular, I don't verbally abuse him, tell him that God hates him, have stereo-playing ruled illegal, have cops bust into places where people play stereos too loud, assault him for indicating his preference for loud music, tell him he can't get married when he finds some partner who likes his same lame music, or consider it reasonable for him to be beaten to death by people suffering from "stereo panic".
I don't love him for it. I don't accept it. I put up with it, because he's my neighbor and that's what he likes doing and in the end it's his life. It is not my right to accept or not accept his behavior. Just like, according to Jesus, it was not the right of that mob to stone the adulterers to death. That's tolerance.
You're about as likely to die from a weekend party pill as you are from your contraceptive pill.
And that turns out to be much safer than skydiving, which seems to weigh in around one death per 100,000 jumps. Funny that the more dangerous one is legal.
Personally, I propose the same solution for both: mandatory licensing. If you want to take MDMA or jump out of planes, you just have to do the six-week course with practical exam at the end.