To be a successful capitalist, you need *surprise* capital to start with.
This is true, and one of the best proofs of it is the success of the microfinance movment, culminating in this year's Nobel for Mohammad Yunus. They have been hugely successful precisely because the number one cause of poverty is lack of capital.
However, I think there's a second good lesson in there for fundamentalist capitalists. The other big reason microfinance generates such amazing financial returns is that the loans come with compulsory education and bind partipants into social networks that give neighbors an interest in each others' successes. It makes it clear to me that Randian model of capitalist as self-improving ubermench is basically a misleading cartoon.
Of course, the success of microfinance also makes it clear to me that the fundamentalist socialists also completely miss the point. By uniting the mechanisms of capitalism with the intentions of the socialists, plus liberal helpings of insight from both camps, microfinance is a big success in both socialist and capitalist terms.
So from the perspective of someone who has been running Debian driven networks for 6+ years and with 5+ years of supporting Debian as a base for commercial development I can say - no thank you, you misunderstood what brings most sysadmins to Debian. It is the best *nix development platform out there.
That sounds great, and I've stuck to Red Hat mainly out of inertia. Do you have any pointers to articles on managing groups of machines efficiently? One place I visited just treated all their Debian boxes as individual boxes, and so every time I used a new lab box I had to do a lot of apt-get stuff just to get things working.
You're assuming that "bounty hunters", so to speak, would write worse code than people doing it for fun. That's an unproven assumption, and it's almost certainly wrong (as evidenced by the number of companies in the world writing software). Indeed, if someone stakes their livelihood on the quality of their code (i.e., they get paid for it), I'd say they're much more likely to be worried about quality.
I'm going to be charitable and assume that you have not actually spent a lot of time programming for a living.
As a consultant, I get to stick my nose in a lot of development shops, and I can pretty much guarantee that the number one cause of shitty software is people trying to do it on the cheap, by which I mean get the most apparent output for their dollars. New, quality-focused methods like Extreme Programming get a fair bit of their boost by making it much harder for the people with the checkbooks to exert time pressure on the programmers. (Instead, the time pressure is redirected into keeping scope as small as possible.)
That's not to say that open-source software is guaranteed to be of high quality. Some of it sucks. But you can be sure that you have removed a major cause of low quality, which is programmers giving up and saying with a sigh: "Well, that's not how I'd do it, but it's your money..."
You're saying that anybody who gets paid to do something does it for the money and doesn't care about the quality of what they do.
There is a vast array of evidence that giving extrinsic rewards (like money) can reduce the quality and creativity of work when compared with intrinsic motivation. That's not to say that all people taking a paycheck will do shitty work. But I can list case after case in my professional life where I've seen reward schemes harm software projects.
For example, I recently charged some people a lot of money to clean up a mostly functional but hugely messy code base. The thing was almost impossible to debug, and completely impossible to improve. There were large amounts of what turned out to be dead code, a bunch of mismatched abstractions, and make-it-work hacks galore. What kind of idiot would build something like that?
It turned out that the programmer was perfectly smart, but the people who had hired him wanted the product really soon, so they structured it as a fixed-price deal with the price dropping every day. Naturally, he rushed, and by the time he pushed it over the line it was a terrible mess.
Also, I think botnets tend to gain and loose IPs fairly rapidly - there'd need to be a way of allowing legitimate users who were once compromised to regain posting power
I probably wouldn't be too quick on this. One of the big problems with compromised machines is that their owners never know and even if they suspect something there's not much incentive to care. If they can't post on their favorite blogs for a month, maybe they'll learn something.
I think people should not just be upset with the spammers, but those who buy from spammers. Spammers just fill a market need. If nobody was buying penis pills, you would never be spammed.
In short, there is no serverside way of preventing a captcha from being relayed to/from a 'processor' be it OCR or human.
I don't think that's what he's proposing exactly. What he's talking about is a centralized IP-based rate-limiting system for CAPTCHAs. Sure, it gets relayed to a human processor, or the human processor does it directly. But if you limit an IP to, say, five comments an hour across all blogs everywhere and impose similar but larger limits on larger blocks, you can make it much harder on the blogs spammers, especially the low-grade ones.
The magic would be in tweaking the system to limit the number of false negatives and false positives. You'd need to make things much looser for proxies like AOL and tighten it up for suspect netblocks and ASNs. But it's perfectly doable, and you'd get the same panoptic benefits that professional anti-spammers like Brightmail do.
Remote sensing (like the WiiRemote) might avoid all the mechanical Dance Pad problems, perhaps?
It would, but there would also be a big drawback: no tactile feedback. With a good pad, you can tell where you are without looking. Another would be that the pad detects where your foot touches the ground, which isn't the same thing as ankle position. So for playing DDR, it wouldn't be so great.
On the other hand, I'm sure that there are other interesting games they could play that would involve ankle-mounted accellerometers and a lot of jumping around, so take this less as a criticism and more as an invitation to explore.
Reducing the number of bugs is not going to be free. It is not going to be easy. If you expect it to be, you are doomed from the start.
I think for the short term, this is completely true. However over the long haul, I think most shops are well away from the optimum, spending more time finding and removing bugs than is efficient. It's the classic, "Well, since we spend 60% of our time in the debugger, there's no way we could afford to write tests." From the stats on my projects, improved quality saves time over the long haul.
Every change that you make in their working environment is a small negative experience to them. Even if it is something that they might agree is a good thing, it is still a change, and thus a negative thing to them.
I think there are two other ways around this. One is that if people are making the change on their own to solve something that bothers them, then they see it as a positive rather than a negative. So a good manager doesn't impose a change in somebody's working environment, but rather helps people to notice the problems they have and to suggest solutions. The other is to have a continuous level of moderate change. If every week you do a retrospective and say, "What do you guys want to do differently next week?" then people will get used to the change and resent when you try to stop.
Do they really believe that you can ever have an exhaustive set of unit tests, no matter what the context? I have seen cases where rewriting a pretty trivial arithmetic expression in a tidier form worked fine on one machine, but completely broke the optimiser with a different compiler on a different OS, resulting in a subtle change in numerical outputs.
I don't think anybody seriously believes that perfection is achievable. However, they do believe that continuous refinement lets you get closer and closer, and that at some point the risks get to an acceptable level. Were I bitten by your example, I'd take it as a lesson that I had failed to express something important in my unit tests and build environment: code should work on OS X with compiler Y. Were that a risk I worried about before, I'd regret that I hadn't taken the time to automate the worrying.
IME the hard-core TDD advocates also have a false sense of security when it comes to design. Just because you have some tests in place, that does not mean you can design on-the-fly all the time, and suffer no overheads.
I missed them saying that. Do you have a reference?
The closest thing I have heard them saying is that test-driven development encourages code that is more modular, more flexible, and better designed than not testing or testing after. It ends up more modular because that's the easiest thing to test. You get more flexibility because as you build you are continually flexing your design in ways that generally are similar to future change, and because you aren't adding things that aren't required by the tests. And you can get better design because you start out thinking about your systems from the outside, focusing more on meaning than mechanism.
As far as I can tell, that's all true. TDD isn't a panacea or the sole practice one might adopt, but every person I've seen adopt it has found benefit in it, both novice designers and experts.
the whole "anything's OK as long as it passes our unit tests" approach is a recipe for endless headaches when your design starts to evolve
If somebody said that and meant it like you do, I'd agree they're wrong. But you're missing one of the most important points: your design shouldn't start to evolve in weeks or months: it should start to evolve from the beginning.
The work of testing is best left to testers. An intermediate 'clear box' test team focused on the development and maintenance of unit tests is far more effective than the traditional dev/test organization that is so prevalent. By getting the development of tough tests out of the hands of the code creators, the tests are more likely to be fiercely objective and less prone to leniency.
I think you're conflating two kinds of testing. To me, unit tests prove that the code does what the developers think it should. Acceptance tests prove that it does what the product managers think it should. Both kinds of testing are useful and necessary. I agree that testing your own code is a problem, but I think an external group is the wrong way to solve that; the feedback loops are too slow -- you learn about problems in hours or days rather than minutes or seconds. Instead, what works for me is Test-Driven Development, Pair Progamming, and collective code ownership.
Test-Driven Development is where I go through 2-10 minute cycles where I write a little test code, make it pass, and then tidy loose ends. Because I write the tests before the code, my tests aren't just verifying things I already think are working. And with Pair Programming, where I and another guy trade the keyboard back and forth every few minutes, I get somebody who keeps me honest and finds the cases I'm not thinking of. That is supported by changing pairs every few hours and having the team share ownership of the code base. If it's everybody's code, then it's a lot harder to think I'm going to clean something up in that imaginary time called "later". When I check it in tonight, somebody else may work on it (and grumble about it) tomorrow morning.
[...] but reality shows that unless management is ready to step on the necks of the development team, that the practices get thrown out the window when projects hit the death march stage.
And there we have the real problem. If the managers let things get to the death march stage, they've already made clear that their priority isn't actually doing good work, it's getting something out regardless of the quality, and favoring the appearance of progress over actual progress. I am fed up with people who say, "Quality is our highest priority -- except for all our other highest priorities." That way leads to poor quality and poor productivity, along with poor morale, high turnover, and immense waste.
However, if specs cannot be trusted from the outset then how can they possibly be useful as the basis for unit tests? Your work to get those tests working will be wasted since you will end up reimplementing them as the specification morphs and solidifies.
The answer is that you work in small units. That lets people focus and get something done. And it's important that those small units of work really let you get something 100% done, some small but complete shippable feature. Personally I prefer those units of work to be no longer than a week. That involves slicing the work differently than most people are used to, but it's worth the effort.
How do small units help? If the suits have said "these 3 features are the top priority for the team this week," then we all have an interest in nailing down the specs for this week's work. Because it's small, it's easier to think about. Because it has to be done by Friday, there's pressure to keep things simple. And in the few days I'm working on something, requirements won't change much. So I just write my unit tests and my code and I'm good to go.
Sure, next week they might change their minds, in which case I've got to change the tests and the code. But that's fine from a business perspective: things change, and we have to live with that. (Some people worry about thrashing, where you do and undo things all the time, but I've never seen that happen; the "what's most important this week" focus makes suits spend developer labor carefully.) And it's fine from a technical perspective, too: changing a code base that's got good tests is much, much easier than changing one without.
Agile methodology, at least as commonly practiced, to be nothing more than the common Waterfall methodology with a stronger emphasis on up-front test development and shorter milestone cycles.
Yes, that's what I think of as Fake Agile. For a while Waterfall people just ignored the Agile stuff. It wasn't like a lot of them were doing Waterfall because they had carefully considered the options and declared Waterfall the best; it was more about conformity to norms. Now enough people are having success with it so the conformists can't just ignore it. But the easy thing is to tinker a little and declare yourself Agile, so that's what they're doing.
Maybe I haven't drank enough of their Kool-aid, but any methodology that prioritizes test development time above code development time assumes too much, IMO.
They don't want to be handing out Kool-aid, really. Agile methods get a lot of their effectiveness from thinking developers who take control of their work and change things to maximize productivity. The basic message of a lot of the Agile luminaries is, "This is what works for me. You should try it and see if it works for you."
To your specific point, the priority of writing tests above production code is only apparent. The main goal is sustainable long-term productivity. Writing code without tests gets you a short-term gain with a long-term cost. Thus, the agilistas only write tests because it helps them go fast.
Really, all good developers test their code, if only manually. When working on something, pretty much everybody makes sure it works. Maybe that's via debug statements or little command-line doodads or by clicking through the app or stepping through in the debugger. The difference with the Agile stuff is that they say you should automate those tests. That way instead of you having to manually check something every time you worry about it, you get the computer to do all the worrying for you. Instead of keeping the important knowledge about a system in your head, you record it. But not in docs, which require a human to verify them. Instead, you put it in code and make Moore's Law your friend.
A big part of my living is helping teams to adopt good practices, and I'm sorry to say that you're going about it all wrong.
At my software company, we occasionally need all engineers to adopt a new standard or 'best practice.' Some are small, like the use of Camel Case for function names, while others have tangible business value, such as 'every check-in must be accompanied by a unit test.' As you might guess, some new practices get ignored, not because people are evil or lazy, but because they're simply too busy to pay attention and change their work habits. So we are seeking creative ways to announce, roll out, and enforce a standard for 100+ engineers so they will actually follow it.
With this attitude you have guaranteed that you will a) probably fail, and b) certainly make things worse.
Engineers generally want to do their work better. If they don't adopt your pet practice, then this means one or more of
the practice is not as good as you think
they don't yet see why the practice is good
their workload is too high, leaving no time or enthusiasm for learning and exploring
in the past you have done other top-down imposition that have undermined the morale and the sense of ownership needed for changes like this
Personally, I think managers should never be imposing practices at all. Engineers are better treated as professionals. You should explain the results you want, and ask what help they need in achieving it.
For CamelCase, for example, you should let people responsible for a particular code base decide how to handle that. Give them the time needed to consider the issue, honor the conclusion they come to, and encourage them to check occasionally to see how they like the results of their decision and whether they want to change it.
For unit testing, requiring a unit test with every checkin is foolish. That's not because testing doesn't work; I use Test-Driven Development and have a bug-in-production rate of less than one a month. But by turning a useful practice into a bullshit requirement, you give them incentive for bullshit compliance and undermine trust. Instead,
Ask for what you actually want: fewer bugs.
Use a Big Visible Chart (yes, paper; yes, hand-drawn; yes, on the wall in a shared space where everybody will see it regularly) to make a bug metric visible.
Ask the developers how to achieve your goal. Unit testing will be one of the answers.
Ask for a team or project that would like to volunteer to try out unit testing and figure out how to make it work in your environment.
Ask them what it will take to make that a reality.
Give them what they ask for. All of it. No pressure, no whining about the cost.
Come back weekly to ask them how it's going and what you can do to help.
The next typical objection is, "What if they ask for classes and books and a reduced workload so that they have time to learn this? That's unacceptable! Can't they just learn it from a couple of articles on the web with no productivity impact?" If that's what you're feeling, then the biggest barrier to adopting good practices at your company isn't your engineers, it's you.
The perl shop sounds cool but from your research it looks like the.Net/MS stuff give you better prospects (but it might be worth looking into what kind of work you'll have - not worth it to make shitty changes to shitty code).
I agree about that last bit, but I wonder if his prospects will really be better.
The way I choose jobs is based on what I can learn, as I think that has a lot of influence on one's prospects. Certainly.NET is a more popular language than Perl. But at the small company, he'll learn a lot more about all sides of a project, whereas large companies tend to break large projects up and pigeonhole people.
When I hire, I look first for people who can solve problems, and only secondarily at the particular languages and toolkits they know. I can get a good programmer productive in whatever environment I'm using through two weeks of pair programming, but breaking people of large-company habits takes a lot longer.
One other factor for the guy to consider is which one is more likely to let him grow. I'd ask both of them, "What if I wanted to try doing some work in another language, like Ruby?" And I'd ask about the histories of the people on the different teams and why they were promoted. I'd be more likely to go with the company where people were more likely to advance on their merits, rather than for political reasons or a willingness to work a bazillion hours pushing a crappy project out the door.
While I agree with that statement regarding music I have to disagree regarding operating systems. Short of Windows the average user has really only two alternatives: OS X or Linux. People aren't going to be buying OS X simply because Windows costs a lot, and I would postulate that very few people would be choosing Linux simply because of the cost (Amongst nerds, yes. General population, no).
Really? I'd bet otherwise. If the choice is paying a big chunk of dough for Windows or getting Linux (which looks about the same these days) for free, I would expect a lot of people to take the free option.
That's especially true in the third-world countries I'm familiar with. There Microsoft owes its hegemony only to lax copyright enforcement policies. And I expect that they're doing it on purpose. Although they convieniently forget it when it comes time to count up the "costs" of piracy, I'm sure they know that letting people who would never buy their software have it for free is just as good for them as the first-hit-is-free approach is for crack dealers.
Example: I know a small company (but stable) that's been searching for an experienced and motivated PHP programmer. And they're willing to pay a decent salary. With all the talk of outsourcing taking away jobs.. how come it's hard to find coders who are motivated and know what they're doing?
Because it is mainly talk. The number of tech jobs is still up. The boom sucked a lot of mediocre people into the field, and I'm sure oursourcing has forced a few of them out again. But salaries for good people are still going up, suggesting that demand is still outstripping supply.
I think this is partly because people are still finding lots of new, interesting things to do with the Internet. As our dear leader says, this is making the pie higher. And it's partly because the field is still evolving at quite a clip, again thanks to the power of the Internet. The technologies I'm using today are very different than the ones I'm was using five years ago, and I'm sure they'll be at least as different five years on. The number of people who can keep up with that pace is not large.
Every time I hear this, I almost feel a little sad. If I didn't have a job writing code, I don't know that I'd write code at home. [...] this notion that someone who's a good problem solver would always be solving problems, and in one particular area (coding, and there's a lot of other areas you can apply your same understanding of logic, math, statistics, process, etc to.)
You're right, I shouldn't have said coding as such. Although a number of the best people I've hired certainly do keep coding in the evenings, some of the good ones are doing other interesting things as well. What I am mainly looking for is that strong bias toward making things happen, with enough consistency of focus that they have deep skills in the field, and enough variety of focus that they appreciate the broader context.
my gut feeling is that if I'm unemployed, I'm going to NOT code for a bit, take a break, get refreshed, then get another job.
In which case, it might more be burnout than lack of personal inclination. Most organizations are set up for forcing reluctant people to work. This is doubly bad for people who love to work: you have to put up with a ton of pointless bullshit, and nobody tries to keep you from burning out. Or it could be that your interests have changed enough that it's time for something else. Some of the most impressive people I know have shifted careers more than once. Either way, it sounds like you have the right strategy: make the decision after you've rested up.
Personally, I'd like to live in a place where I've got at least a ghost of a chance of buying a decent 3 bedroom plus an office house without needing a galactic-scale interest only ARM.
In the Bay Area, the solution right now is to rent, not buy. The ratio between rents and home prices are at historic highs; to buy the place I'm living in would cost me nearly twice as much per month. Academics are predicting a 10% drop in housing prices, which might mean your entire down payment would be lost. If things go worse, you'd have to pay money to move out.
So just rent, and sock the extra dough away for when you move back to a place with a property market that isn't completely insane.
a paltry 16% more than I make in nowheresville, South Carolina
You negotiated, right? I'm assuming yes, but for the rest of the readers let me say that I'm shocked at the number of techies who don't bother to negotiate salaries. In your situation, for example, I'd find a cost-of-living calculator and get hard numbers on the difference between the two locales. Then I'd reply saying, "I'd love to work for you, but you're asking me to take an effective pay cut. Take a look at these numbers..." and attach the references.
For those scared of negotiating, immediately go get the book, Getting to Yes. It tells you how to negotiate without it devolving into some sort of unpleasant villiage market drama. It's a short, readable book, and even a minor improvement in your next salary negotiation can mean thousands of dollars.
I think things like pay, benefits, location, etc. matter far more to the vast majority of techies than merely "working on a prominent website."
I disagree.
Part of what makes great people great is that they are very excited about their work. Maybe they're excited about the technical challenges, maybe it's about the product itself. You don't want them just waiting for quitting time; you want them to be so excited that you kick them out at the end of the day so they don't burn out. They are the people who would if they weren't doing it as a job would be writing code in the evenings because they love it.
That's not to say that pay, benefits, and location don't matter. But for getting the best, you just have to provide an equivalent package to what they could get elsewhere. They'll make the decision based on how much they like the work and the people.
So now that I think about it, we probably are in agreement. The majority of techies really might care more about the money than the work. If so, you're welcome to all of 'em. I wouldn't people like that anyhow.
did you ever really think that the Republican Congress would not pass acts enabling wiretapping and dismantling oversight, enabling torture and disabling oversight, enabling arbitrary arrests, and disabling oversight.
To be frank, yes I did.
I have a number of issues with typical Republican positions, but I've always been a fan of their distrust of centralized authority. Ditto their sense of fiscal responsibility, their promotion of individual liberty, and the belief that individual responsibility goes along with that. When W was elected I was disappointed, but had some hope that they'd accomplish some good in areas that Democrats were missing unarguably missing. Instead we've gotten corruption, statism, theocracy, cronyism, profligacy, jingoism, and authoritarian leanings more suited to a feudal monarchy than to what I want to believe is the world's most robust democracy.
And torture? That someone wearing my flag would torture people? To me, this is the deepest betrayal of what America stands for. I am outraged. And the weasel words and sophistry around it only makes it worse. I have no idea what happened to the Republican party or the people in it whose ideals I respect. But I hope that this is a temporary abberation that will be cured by a drubbing in the next couple of elections.
Now they won't allow him to do anything unless he comes up with a legal ID that has his nickname on it. They don't care that he was paying with his legal name for the last X years.
File a "doing business as" or incorporate. The first is pretty cheap in most places; the other may cost a few bucks depending on local law. That will make it legal to business in that name, and GoDaddy will hopefully respect that.
The government in the USA is utterly and thoroughly corrupt.
That sounds excitingly dramatic, but do you have any data to back that up? Having lived in a few different countries, I don't think it's nearly so dire. And neither the Corruption Perceptions Index nor the Global Corruption Barometer support your claim.
That's not to say that there isn't some corruption, but I think you haven't thought very much about what utterly and thoroughly corrupt could mean. You may find comparisons with what goes on in Russia, China, or most of Africa instructive, for example.
Uhm... okay. So if I start compiling and publishing a list of all criminals *and* accused defendants for use by employers in weeding out potential problems, then I'm not guilty of libel? After all, I'm just posting a list. And if a few people who aren't guilty get included, well, it's not *my* fault most businesses used my list in their hiring practices. After all, I'm just publishing a list.
Your analogy isn't correct. Because you are making assertions about whether or not they are criminals, incorrect listings mean libel. However, if you just publish a list of people you recommend against hiring, then you aren't guilty of anything. People may choose to listen or not.
This situation already has existed for decades for things like bond ratings. You can't sue a ratings agency for their opinion that your company isn't a good financial risk. They get to have their opinion, and they get to publish it, no matter how negative it is, and whether or not they're actually right. But like Spamhaus, the amount people pay attention to them is related to the quality of their work.
The trend of software-as-a-service is not coincidental with this situation. In 5 to 10 years the base software we use might be so complex and tough to work on, that the only way it can be sustained is by small, regular payments, and the updates will be small, incremental, security/performance oriented. No more big releases, no more rushes to fix bugs in the last moment.
I think the interesting part will come when we see large, old code bases that started in the software-as-service world. A few years back I switched to weekly iterations, and saw my productivity go up and my bug rates go down. My bet is a lot of the horrors you describe are the result of long product cycles.
I was a little disappointed to realize that people outside of software are familiar with this effect; "don't bite off more than you can chew" is something I now feel applies to a lot of software projects. I think a lot of code bases are terrible because people are used to spending months writing possibly dodgy code and then months more trying to clean it up. Working on a much smaller scale makes it easy to work clean. And if the iteration ends in a couple of days, it's a lot harder to pretend that something will get cleaned up "later".
As a bonus, producing a regular stream of software pacifies managers and customers, whose anxiety over the hoped-for upcoming release seems to be the source of a lot of the crazy.
Slashdot Mirror
To be a successful capitalist, you need *surprise* capital to start with.
This is true, and one of the best proofs of it is the success of the microfinance movment, culminating in this year's Nobel for Mohammad Yunus. They have been hugely successful precisely because the number one cause of poverty is lack of capital.
However, I think there's a second good lesson in there for fundamentalist capitalists. The other big reason microfinance generates such amazing financial returns is that the loans come with compulsory education and bind partipants into social networks that give neighbors an interest in each others' successes. It makes it clear to me that Randian model of capitalist as self-improving ubermench is basically a misleading cartoon.
Of course, the success of microfinance also makes it clear to me that the fundamentalist socialists also completely miss the point. By uniting the mechanisms of capitalism with the intentions of the socialists, plus liberal helpings of insight from both camps, microfinance is a big success in both socialist and capitalist terms.
So from the perspective of someone who has been running Debian driven networks for 6+ years and with 5+ years of supporting Debian as a base for commercial development I can say - no thank you, you misunderstood what brings most sysadmins to Debian. It is the best *nix development platform out there.
That sounds great, and I've stuck to Red Hat mainly out of inertia. Do you have any pointers to articles on managing groups of machines efficiently? One place I visited just treated all their Debian boxes as individual boxes, and so every time I used a new lab box I had to do a lot of apt-get stuff just to get things working.
You're assuming that "bounty hunters", so to speak, would write worse code than people doing it for fun. That's an unproven assumption, and it's almost certainly wrong (as evidenced by the number of companies in the world writing software). Indeed, if someone stakes their livelihood on the quality of their code (i.e., they get paid for it), I'd say they're much more likely to be worried about quality.
I'm going to be charitable and assume that you have not actually spent a lot of time programming for a living.
As a consultant, I get to stick my nose in a lot of development shops, and I can pretty much guarantee that the number one cause of shitty software is people trying to do it on the cheap, by which I mean get the most apparent output for their dollars. New, quality-focused methods like Extreme Programming get a fair bit of their boost by making it much harder for the people with the checkbooks to exert time pressure on the programmers. (Instead, the time pressure is redirected into keeping scope as small as possible.)
That's not to say that open-source software is guaranteed to be of high quality. Some of it sucks. But you can be sure that you have removed a major cause of low quality, which is programmers giving up and saying with a sigh: "Well, that's not how I'd do it, but it's your money..."
You're saying that anybody who gets paid to do something does it for the money and doesn't care about the quality of what they do.
There is a vast array of evidence that giving extrinsic rewards (like money) can reduce the quality and creativity of work when compared with intrinsic motivation. That's not to say that all people taking a paycheck will do shitty work. But I can list case after case in my professional life where I've seen reward schemes harm software projects.
For example, I recently charged some people a lot of money to clean up a mostly functional but hugely messy code base. The thing was almost impossible to debug, and completely impossible to improve. There were large amounts of what turned out to be dead code, a bunch of mismatched abstractions, and make-it-work hacks galore. What kind of idiot would build something like that?
It turned out that the programmer was perfectly smart, but the people who had hired him wanted the product really soon, so they structured it as a fixed-price deal with the price dropping every day. Naturally, he rushed, and by the time he pushed it over the line it was a terrible mess.
Also, I think botnets tend to gain and loose IPs fairly rapidly - there'd need to be a way of allowing legitimate users who were once compromised to regain posting power
I probably wouldn't be too quick on this. One of the big problems with compromised machines is that their owners never know and even if they suspect something there's not much incentive to care. If they can't post on their favorite blogs for a month, maybe they'll learn something.
I think people should not just be upset with the spammers, but those who buy from spammers. Spammers just fill a market need. If nobody was buying penis pills, you would never be spammed.
Don't worry: I have enough upset to go around.
In short, there is no serverside way of preventing a captcha from being relayed to/from a 'processor' be it OCR or human.
I don't think that's what he's proposing exactly. What he's talking about is a centralized IP-based rate-limiting system for CAPTCHAs. Sure, it gets relayed to a human processor, or the human processor does it directly. But if you limit an IP to, say, five comments an hour across all blogs everywhere and impose similar but larger limits on larger blocks, you can make it much harder on the blogs spammers, especially the low-grade ones.
The magic would be in tweaking the system to limit the number of false negatives and false positives. You'd need to make things much looser for proxies like AOL and tighten it up for suspect netblocks and ASNs. But it's perfectly doable, and you'd get the same panoptic benefits that professional anti-spammers like Brightmail do.
Remote sensing (like the WiiRemote) might avoid all the mechanical Dance Pad problems, perhaps?
It would, but there would also be a big drawback: no tactile feedback. With a good pad, you can tell where you are without looking. Another would be that the pad detects where your foot touches the ground, which isn't the same thing as ankle position. So for playing DDR, it wouldn't be so great.
On the other hand, I'm sure that there are other interesting games they could play that would involve ankle-mounted accellerometers and a lot of jumping around, so take this less as a criticism and more as an invitation to explore.
Reducing the number of bugs is not going to be free. It is not going to be easy. If you expect it to be, you are doomed from the start.
I think for the short term, this is completely true. However over the long haul, I think most shops are well away from the optimum, spending more time finding and removing bugs than is efficient. It's the classic, "Well, since we spend 60% of our time in the debugger, there's no way we could afford to write tests." From the stats on my projects, improved quality saves time over the long haul.
Every change that you make in their working environment is a small negative experience to them. Even if it is something that they might agree is a good thing, it is still a change, and thus a negative thing to them.
I think there are two other ways around this. One is that if people are making the change on their own to solve something that bothers them, then they see it as a positive rather than a negative. So a good manager doesn't impose a change in somebody's working environment, but rather helps people to notice the problems they have and to suggest solutions. The other is to have a continuous level of moderate change. If every week you do a retrospective and say, "What do you guys want to do differently next week?" then people will get used to the change and resent when you try to stop.
Do they really believe that you can ever have an exhaustive set of unit tests, no matter what the context? I have seen cases where rewriting a pretty trivial arithmetic expression in a tidier form worked fine on one machine, but completely broke the optimiser with a different compiler on a different OS, resulting in a subtle change in numerical outputs.
I don't think anybody seriously believes that perfection is achievable. However, they do believe that continuous refinement lets you get closer and closer, and that at some point the risks get to an acceptable level. Were I bitten by your example, I'd take it as a lesson that I had failed to express something important in my unit tests and build environment: code should work on OS X with compiler Y. Were that a risk I worried about before, I'd regret that I hadn't taken the time to automate the worrying.
IME the hard-core TDD advocates also have a false sense of security when it comes to design. Just because you have some tests in place, that does not mean you can design on-the-fly all the time, and suffer no overheads.
I missed them saying that. Do you have a reference?
The closest thing I have heard them saying is that test-driven development encourages code that is more modular, more flexible, and better designed than not testing or testing after. It ends up more modular because that's the easiest thing to test. You get more flexibility because as you build you are continually flexing your design in ways that generally are similar to future change, and because you aren't adding things that aren't required by the tests. And you can get better design because you start out thinking about your systems from the outside, focusing more on meaning than mechanism.
As far as I can tell, that's all true. TDD isn't a panacea or the sole practice one might adopt, but every person I've seen adopt it has found benefit in it, both novice designers and experts.
the whole "anything's OK as long as it passes our unit tests" approach is a recipe for endless headaches when your design starts to evolve
If somebody said that and meant it like you do, I'd agree they're wrong. But you're missing one of the most important points: your design shouldn't start to evolve in weeks or months: it should start to evolve from the beginning.
The work of testing is best left to testers. An intermediate 'clear box' test team focused on the development and maintenance of unit tests is far more effective than the traditional dev/test organization that is so prevalent. By getting the development of tough tests out of the hands of the code creators, the tests are more likely to be fiercely objective and less prone to leniency.
I think you're conflating two kinds of testing. To me, unit tests prove that the code does what the developers think it should. Acceptance tests prove that it does what the product managers think it should. Both kinds of testing are useful and necessary. I agree that testing your own code is a problem, but I think an external group is the wrong way to solve that; the feedback loops are too slow -- you learn about problems in hours or days rather than minutes or seconds. Instead, what works for me is Test-Driven Development, Pair Progamming, and collective code ownership.
Test-Driven Development is where I go through 2-10 minute cycles where I write a little test code, make it pass, and then tidy loose ends. Because I write the tests before the code, my tests aren't just verifying things I already think are working. And with Pair Programming, where I and another guy trade the keyboard back and forth every few minutes, I get somebody who keeps me honest and finds the cases I'm not thinking of. That is supported by changing pairs every few hours and having the team share ownership of the code base. If it's everybody's code, then it's a lot harder to think I'm going to clean something up in that imaginary time called "later". When I check it in tonight, somebody else may work on it (and grumble about it) tomorrow morning.
[...] but reality shows that unless management is ready to step on the necks of the development team, that the practices get thrown out the window when projects hit the death march stage.
And there we have the real problem. If the managers let things get to the death march stage, they've already made clear that their priority isn't actually doing good work, it's getting something out regardless of the quality, and favoring the appearance of progress over actual progress. I am fed up with people who say, "Quality is our highest priority -- except for all our other highest priorities." That way leads to poor quality and poor productivity, along with poor morale, high turnover, and immense waste.
However, if specs cannot be trusted from the outset then how can they possibly be useful as the basis for unit tests? Your work to get those tests working will be wasted since you will end up reimplementing them as the specification morphs and solidifies.
The answer is that you work in small units. That lets people focus and get something done. And it's important that those small units of work really let you get something 100% done, some small but complete shippable feature. Personally I prefer those units of work to be no longer than a week. That involves slicing the work differently than most people are used to, but it's worth the effort.
How do small units help? If the suits have said "these 3 features are the top priority for the team this week," then we all have an interest in nailing down the specs for this week's work. Because it's small, it's easier to think about. Because it has to be done by Friday, there's pressure to keep things simple. And in the few days I'm working on something, requirements won't change much. So I just write my unit tests and my code and I'm good to go.
Sure, next week they might change their minds, in which case I've got to change the tests and the code. But that's fine from a business perspective: things change, and we have to live with that. (Some people worry about thrashing, where you do and undo things all the time, but I've never seen that happen; the "what's most important this week" focus makes suits spend developer labor carefully.) And it's fine from a technical perspective, too: changing a code base that's got good tests is much, much easier than changing one without.
Agile methodology, at least as commonly practiced, to be nothing more than the common Waterfall methodology with a stronger emphasis on up-front test development and shorter milestone cycles.
Yes, that's what I think of as Fake Agile. For a while Waterfall people just ignored the Agile stuff. It wasn't like a lot of them were doing Waterfall because they had carefully considered the options and declared Waterfall the best; it was more about conformity to norms. Now enough people are having success with it so the conformists can't just ignore it. But the easy thing is to tinker a little and declare yourself Agile, so that's what they're doing.
Maybe I haven't drank enough of their Kool-aid, but any methodology that prioritizes test development time above code development time assumes too much, IMO.
They don't want to be handing out Kool-aid, really. Agile methods get a lot of their effectiveness from thinking developers who take control of their work and change things to maximize productivity. The basic message of a lot of the Agile luminaries is, "This is what works for me. You should try it and see if it works for you."
To your specific point, the priority of writing tests above production code is only apparent. The main goal is sustainable long-term productivity. Writing code without tests gets you a short-term gain with a long-term cost. Thus, the agilistas only write tests because it helps them go fast.
Really, all good developers test their code, if only manually. When working on something, pretty much everybody makes sure it works. Maybe that's via debug statements or little command-line doodads or by clicking through the app or stepping through in the debugger. The difference with the Agile stuff is that they say you should automate those tests. That way instead of you having to manually check something every time you worry about it, you get the computer to do all the worrying for you. Instead of keeping the important knowledge about a system in your head, you record it. But not in docs, which require a human to verify them. Instead, you put it in code and make Moore's Law your friend.
At my software company, we occasionally need all engineers to adopt a new standard or 'best practice.' Some are small, like the use of Camel Case for function names, while others have tangible business value, such as 'every check-in must be accompanied by a unit test.' As you might guess, some new practices get ignored, not because people are evil or lazy, but because they're simply too busy to pay attention and change their work habits. So we are seeking creative ways to announce, roll out, and enforce a standard for 100+ engineers so they will actually follow it.
With this attitude you have guaranteed that you will a) probably fail, and b) certainly make things worse.
Engineers generally want to do their work better. If they don't adopt your pet practice, then this means one or more of
- the practice is not as good as you think
- they don't yet see why the practice is good
- their workload is too high, leaving no time or enthusiasm for learning and exploring
- in the past you have done other top-down imposition that have undermined the morale and the sense of ownership needed for changes like this
Personally, I think managers should never be imposing practices at all. Engineers are better treated as professionals. You should explain the results you want, and ask what help they need in achieving it.For CamelCase, for example, you should let people responsible for a particular code base decide how to handle that. Give them the time needed to consider the issue, honor the conclusion they come to, and encourage them to check occasionally to see how they like the results of their decision and whether they want to change it.
For unit testing, requiring a unit test with every checkin is foolish. That's not because testing doesn't work; I use Test-Driven Development and have a bug-in-production rate of less than one a month. But by turning a useful practice into a bullshit requirement, you give them incentive for bullshit compliance and undermine trust. Instead,
- Ask for what you actually want: fewer bugs.
- Use a Big Visible Chart (yes, paper; yes, hand-drawn; yes, on the wall in a shared space where everybody will see it regularly) to make a bug metric visible.
- Ask the developers how to achieve your goal. Unit testing will be one of the answers.
- Ask for a team or project that would like to volunteer to try out unit testing and figure out how to make it work in your environment.
- Ask them what it will take to make that a reality.
- Give them what they ask for. All of it. No pressure, no whining about the cost.
- Come back weekly to ask them how it's going and what you can do to help.
The next typical objection is, "What if they ask for classes and books and a reduced workload so that they have time to learn this? That's unacceptable! Can't they just learn it from a couple of articles on the web with no productivity impact?" If that's what you're feeling, then the biggest barrier to adopting good practices at your company isn't your engineers, it's you.The perl shop sounds cool but from your research it looks like the .Net/MS stuff give you better prospects (but it might be worth looking into what kind of work you'll have - not worth it to make shitty changes to shitty code).
.NET is a more popular language than Perl. But at the small company, he'll learn a lot more about all sides of a project, whereas large companies tend to break large projects up and pigeonhole people.
I agree about that last bit, but I wonder if his prospects will really be better.
The way I choose jobs is based on what I can learn, as I think that has a lot of influence on one's prospects. Certainly
When I hire, I look first for people who can solve problems, and only secondarily at the particular languages and toolkits they know. I can get a good programmer productive in whatever environment I'm using through two weeks of pair programming, but breaking people of large-company habits takes a lot longer.
One other factor for the guy to consider is which one is more likely to let him grow. I'd ask both of them, "What if I wanted to try doing some work in another language, like Ruby?" And I'd ask about the histories of the people on the different teams and why they were promoted. I'd be more likely to go with the company where people were more likely to advance on their merits, rather than for political reasons or a willingness to work a bazillion hours pushing a crappy project out the door.
While I agree with that statement regarding music I have to disagree regarding operating systems. Short of Windows the average user has really only two alternatives: OS X or Linux. People aren't going to be buying OS X simply because Windows costs a lot, and I would postulate that very few people would be choosing Linux simply because of the cost (Amongst nerds, yes. General population, no).
Really? I'd bet otherwise. If the choice is paying a big chunk of dough for Windows or getting Linux (which looks about the same these days) for free, I would expect a lot of people to take the free option.
That's especially true in the third-world countries I'm familiar with. There Microsoft owes its hegemony only to lax copyright enforcement policies. And I expect that they're doing it on purpose. Although they convieniently forget it when it comes time to count up the "costs" of piracy, I'm sure they know that letting people who would never buy their software have it for free is just as good for them as the first-hit-is-free approach is for crack dealers.
Example: I know a small company (but stable) that's been searching for an experienced and motivated PHP programmer. And they're willing to pay a decent salary. With all the talk of outsourcing taking away jobs .. how come it's hard to find coders who are motivated and know what they're doing?
Because it is mainly talk. The number of tech jobs is still up. The boom sucked a lot of mediocre people into the field, and I'm sure oursourcing has forced a few of them out again. But salaries for good people are still going up, suggesting that demand is still outstripping supply.
I think this is partly because people are still finding lots of new, interesting things to do with the Internet. As our dear leader says, this is making the pie higher. And it's partly because the field is still evolving at quite a clip, again thanks to the power of the Internet. The technologies I'm using today are very different than the ones I'm was using five years ago, and I'm sure they'll be at least as different five years on. The number of people who can keep up with that pace is not large.
Every time I hear this, I almost feel a little sad. If I didn't have a job writing code, I don't know that I'd write code at home. [...] this notion that someone who's a good problem solver would always be solving problems, and in one particular area (coding, and there's a lot of other areas you can apply your same understanding of logic, math, statistics, process, etc to.)
You're right, I shouldn't have said coding as such. Although a number of the best people I've hired certainly do keep coding in the evenings, some of the good ones are doing other interesting things as well. What I am mainly looking for is that strong bias toward making things happen, with enough consistency of focus that they have deep skills in the field, and enough variety of focus that they appreciate the broader context.
my gut feeling is that if I'm unemployed, I'm going to NOT code for a bit, take a break, get refreshed, then get another job.
In which case, it might more be burnout than lack of personal inclination. Most organizations are set up for forcing reluctant people to work. This is doubly bad for people who love to work: you have to put up with a ton of pointless bullshit, and nobody tries to keep you from burning out. Or it could be that your interests have changed enough that it's time for something else. Some of the most impressive people I know have shifted careers more than once. Either way, it sounds like you have the right strategy: make the decision after you've rested up.
Personally, I'd like to live in a place where I've got at least a ghost of a chance of buying a decent 3 bedroom plus an office house without needing a galactic-scale interest only ARM.
In the Bay Area, the solution right now is to rent, not buy. The ratio between rents and home prices are at historic highs; to buy the place I'm living in would cost me nearly twice as much per month. Academics are predicting a 10% drop in housing prices, which might mean your entire down payment would be lost. If things go worse, you'd have to pay money to move out.
So just rent, and sock the extra dough away for when you move back to a place with a property market that isn't completely insane.
a paltry 16% more than I make in nowheresville, South Carolina
You negotiated, right? I'm assuming yes, but for the rest of the readers let me say that I'm shocked at the number of techies who don't bother to negotiate salaries. In your situation, for example, I'd find a cost-of-living calculator and get hard numbers on the difference between the two locales. Then I'd reply saying, "I'd love to work for you, but you're asking me to take an effective pay cut. Take a look at these numbers..." and attach the references.
For those scared of negotiating, immediately go get the book, Getting to Yes . It tells you how to negotiate without it devolving into some sort of unpleasant villiage market drama. It's a short, readable book, and even a minor improvement in your next salary negotiation can mean thousands of dollars.
I think things like pay, benefits, location, etc. matter far more to the vast majority of techies than merely "working on a prominent website."
I disagree.
Part of what makes great people great is that they are very excited about their work. Maybe they're excited about the technical challenges, maybe it's about the product itself. You don't want them just waiting for quitting time; you want them to be so excited that you kick them out at the end of the day so they don't burn out. They are the people who would if they weren't doing it as a job would be writing code in the evenings because they love it.
That's not to say that pay, benefits, and location don't matter. But for getting the best, you just have to provide an equivalent package to what they could get elsewhere. They'll make the decision based on how much they like the work and the people.
So now that I think about it, we probably are in agreement. The majority of techies really might care more about the money than the work. If so, you're welcome to all of 'em. I wouldn't people like that anyhow.
did you ever really think that the Republican Congress would not pass acts enabling wiretapping and dismantling oversight, enabling torture and disabling oversight, enabling arbitrary arrests, and disabling oversight.
To be frank, yes I did.
I have a number of issues with typical Republican positions, but I've always been a fan of their distrust of centralized authority. Ditto their sense of fiscal responsibility, their promotion of individual liberty, and the belief that individual responsibility goes along with that. When W was elected I was disappointed, but had some hope that they'd accomplish some good in areas that Democrats were missing unarguably missing. Instead we've gotten corruption, statism, theocracy, cronyism, profligacy, jingoism, and authoritarian leanings more suited to a feudal monarchy than to what I want to believe is the world's most robust democracy.
And torture? That someone wearing my flag would torture people? To me, this is the deepest betrayal of what America stands for. I am outraged. And the weasel words and sophistry around it only makes it worse. I have no idea what happened to the Republican party or the people in it whose ideals I respect. But I hope that this is a temporary abberation that will be cured by a drubbing in the next couple of elections.
Now they won't allow him to do anything unless he comes up with a legal ID that has his nickname on it. They don't care that he was paying with his legal name for the last X years.
File a "doing business as" or incorporate. The first is pretty cheap in most places; the other may cost a few bucks depending on local law. That will make it legal to business in that name, and GoDaddy will hopefully respect that.
The government in the USA is utterly and thoroughly corrupt.
That sounds excitingly dramatic, but do you have any data to back that up? Having lived in a few different countries, I don't think it's nearly so dire. And neither the Corruption Perceptions Index nor the Global Corruption Barometer support your claim.
That's not to say that there isn't some corruption, but I think you haven't thought very much about what utterly and thoroughly corrupt could mean. You may find comparisons with what goes on in Russia, China, or most of Africa instructive, for example.
Uhm... okay. So if I start compiling and publishing a list of all criminals *and* accused defendants for use by employers in weeding out potential problems, then I'm not guilty of libel? After all, I'm just posting a list. And if a few people who aren't guilty get included, well, it's not *my* fault most businesses used my list in their hiring practices. After all, I'm just publishing a list.
Your analogy isn't correct. Because you are making assertions about whether or not they are criminals, incorrect listings mean libel. However, if you just publish a list of people you recommend against hiring, then you aren't guilty of anything. People may choose to listen or not.
This situation already has existed for decades for things like bond ratings. You can't sue a ratings agency for their opinion that your company isn't a good financial risk. They get to have their opinion, and they get to publish it, no matter how negative it is, and whether or not they're actually right. But like Spamhaus, the amount people pay attention to them is related to the quality of their work.
The trend of software-as-a-service is not coincidental with this situation. In 5 to 10 years the base software we use might be so complex and tough to work on, that the only way it can be sustained is by small, regular payments, and the updates will be small, incremental, security/performance oriented. No more big releases, no more rushes to fix bugs in the last moment.
I think the interesting part will come when we see large, old code bases that started in the software-as-service world. A few years back I switched to weekly iterations, and saw my productivity go up and my bug rates go down. My bet is a lot of the horrors you describe are the result of long product cycles.
I was a little disappointed to realize that people outside of software are familiar with this effect; "don't bite off more than you can chew" is something I now feel applies to a lot of software projects. I think a lot of code bases are terrible because people are used to spending months writing possibly dodgy code and then months more trying to clean it up. Working on a much smaller scale makes it easy to work clean. And if the iteration ends in a couple of days, it's a lot harder to pretend that something will get cleaned up "later".
As a bonus, producing a regular stream of software pacifies managers and customers, whose anxiety over the hoped-for upcoming release seems to be the source of a lot of the crazy.