It may not be useful for full-time, on-site, permantent employment. In my experience there, noone cares what you did if you weren't paid to do it.
However, on the other side of that, open source experience can be very valuable when seeking off-site, outsource development work. When I am looking for people to hire for that kind of work, is it *extremely* useful for them to have some code they can show me (open source!) so I can see what kind of code they write. If I am comparing developer A and developer B, and A says he wrote some great stuff but can't show me a line of it, and B says I can go look at his code, it's a lot easier to hire B.
I would find it much more convenient if PuTTY would store its settings in a "putty.ini" file or whatever. That would be easier to move to another computer as needed. (It can be done now, by exporting the appropriate part of the registry.)
An effective way to fight this, and any other form of price pressure on hourly rates, is to deliver fixed deliverables for a fixed price, or other pricing methods that are not based on hours.
(Of course, there are also plenty of perils therein.)
[There's only so much a methodology can bring to the table -- after that it's about finding and keeping a competant staff who understand the value of what they're doing.]
You are so utterly right. The key idea is "people over process". I've rather have 5 great people with any old process, than 25 mediocre people with the perfect process.
[look at the console gaming industry for tips]
I have always been impressed with the gaming industry for this reason. Sometime people erroneously think of game programming as being somehow less "heavy duty" than business apps, etc. But games are usually under incredible schedule pressure (for vital marketing reasons) yet also need to ship very few bugs, because buyers are prone to return a game that doesn't work, not become a source of upgrade revenues.
[not the fake customer on your XP team, the real customer holding the checkbook]
XP says to have the real customer. If you have a fake customer, it's not "pure" XP. Many people who like XP but can't get a real customer use a "proxy customer", but they (hopefully) admit that they aren't really doing XP per se, just something similar to it.
You are of course 100% right that satisfying a fake customer is irrelevant if you don't satisfy the person with the checkbook! In my mind, customer equals check-writer.
[There's a great deal of XP fundamentalism out there, mostly on the part of development managers]
That actually doesn't match my experience at all. I see many developers who are very excited about XP, but many development managers seem to like some of the ideas but be *far* from "fundamentalists" about it. Rather they want to immediately disregard major portions of it, typically.
[about as atomic as you can get in an asynchronous system]
I've built a number of asyncronous systems, and agree they can be challenging. I do believe it makes testing even more important. If I was building the system you describe, I would probably insist on testing that piece.
Regarding choosings unit tests, the frequent advice is to test everything that could possibly break, which is pretty vague - but it definately includes this async beast.
[Well, I can't point to any project that managed to successfully implement "pure" XP]
[didn't have enough staffing to constantly pair program] etc.
My last project didn't do RUP. And it didn't do Scrum, although we no doubt did bits and pieces of each. I don't use it as an example of either of those methods succeeding or failing.
Your projects didn't do XP, it did bits and pieces of it, omitting large important portions. So why would it indicate anything about XP? Because the people talked about XP a lot while they did something different?
[The Cult of XP claims to have the one right and true solution]
I've read thousands of messages on the XP mailing list, I've been to an XP conference, I've read a few of the books, and I've seen presentations by most of "big names". In the process, I have not seen such claims.
[asynchronous input from five different sources, where that input consists of five different complex packages]
I've found that it makes a lot more sense to focus on testing the hard stuff, like this, than simple things like the ones you mentioned. By the way, it's also quite useful (totally apart from XP) to decompose such a beast into pieces you can test effectively.
[so don't sacrifice your project and your customer on the altar of XP]
I've never heard of this happening. Can you point to any project which did XP (most or all of it, not just talked about it) and resulted in an unhappy customer for that reason?
I've mostly seen people do little bits of XP (ignoring most of it), fail, and blame XP. A typical story is "we did XP, but we didn't do much testing, we didn't pair program, we didn't have a customer on site, we didn't integrate very often, we didn't track our progress, and our project went badly, therefore XP is bad". Weird.
[unwillingness to sacrifice key features in order to make time to build unit tests for every radio button]
Personally, I do test-intensive coding because it helps me go faster (build more functionality per unit time). If it didn't, I wouldn't. I also don't see the point in unit testing a radio button.
Rural areas are usually cheaper primarily in terms of housing expenses, and restaurants. However, a great many things in life cost generally the same in rural areas as anythere else:
[Low gas prices today are instrumental in ensuring continued dependency tomorrow]
Ah... so if prices are high, it must be because of a conspiracy. If prices are low, it must be because of a conspiracy:-)
Conspiracies might or might not exist. But I don't think that high or low prices per se are evidence of anything.
The comment about Enron execs and bonuses is right on, although it has nothing to do with the industry they are in. It often appears that large publicly traded companies are operated more for the benefit of top management than for the benefit of the owners (stockholders). As someone who owns some stock but it not an executive at a large firm, this annoys me.
[they'd be propping up prices to stop them from falling so low]
Perhaps the conspiracy theory needs to be amended with an explanation that while the conspirators are clever enough to operate a vast network of wrongdoing without detection, they just aren't smart enough to figure out how to actually make oil prices go up. If I was one of these theoretical Big Oil execs with a bunch of politicians on the payroll, I'd fire them, they're doing a lousy job. I put gas in my car the other day for 98 cents a gallon.
On the other hand, perhaps we should consider the possibility that George W. just might have things on this *other* than oil companies.
To some extent, the purpose of a smokestack is to get the junk that comes out of it to disperse widely, over lot of people far away who can't do much about it, rather than locally, over the people close enough to it to be able to do something about it politically.
[Not only does my employer need to find someone who can code in C, C++, Java, Perl, Python, shell script, and assembler]
You are certainly right in the extreme case, but this is often overdone. If your employer is not hiring people who can learn a bit of Python when they need it, perhaps they should hire different people. If you can save a lot of time and money why adding a second language to a project, it may well be worthwhile. Adding the 5th language very likely is never worth it.
You are right, but this is sometimes taken too far. Some companies / managers have a wildly over-inflated idea of the effort of switching to new tools or new languages.
Indeed, you are right about both the post and the drives.
However, there are lots of situations for which people have a need for very large storage, but don't have a need for 99.99999% uptime, amazing reliability, etc., and you can now buy the former for much less cost than the latter. Three years ago, if you needed terabyte, you had to spend a huge amount on an EMC or whatever; now, you only have to spend that if you need a huge amount *and* you need great reliability.
The world keeps changing, too. In a few more years, if you need a terabyte, that will be one hard drive. If you need higher availability, you'll need just a normal RAID subsystem, which is included in many servers and is far cheaper than an EMC storage system.
I remember looking at a 10 gig storage subsystem for a document imaging application some years ago. It was an optical disk system with a robotic arm for swapping a library of disks, $20K+ Today my notebook has that much space.
Slashdot Mirror
IANAL, but I am under the impression that this often includes any contract to buy/sell real estate.
This is a very good point.
The risk of a house burning down is low. The risk of a house currently on fire burning down is higher.
It may not be useful for full-time, on-site, permantent employment. In my experience there, noone cares what you did if you weren't paid to do it.
However, on the other side of that, open source experience can be very valuable when seeking off-site, outsource development work. When I am looking for people to hire for that kind of work, is it *extremely* useful for them to have some code they can show me (open source!) so I can see what kind of code they write. If I am comparing developer A and developer B, and A says he wrote some great stuff but can't show me a line of it, and B says I can go look at his code, it's a lot easier to hire B.
[cause employers to move from massive down-town centers, to more localized live/work/shop communities.]
Isn't this another way of describing sprawl?
I would find it much more convenient if PuTTY would store its settings in a "putty.ini" file or whatever. That would be easier to move to another computer as needed. (It can be done now, by exporting the appropriate part of the registry.)
I use SpeakEasy. They are widely regarded as an excellent ISP. I recommend they highly.
:-)
They don't host my web site. They don't mind if I use their SMTP server to send email "From:" my domain which they do not host.
Thus, I disagree with your statement about any good ISP not allowing this, by presenting an example of a very good ISP that does
An effective way to fight this, and any other form of price pressure on hourly rates, is to deliver fixed deliverables for a fixed price, or other pricing methods that are not based on hours.
(Of course, there are also plenty of perils therein.)
That's a very good point about console games.
I hadn't thought of that, I was thinking of games that run on a PC. PC games get the "best of both worlds", so to speak.
[There's only so much a methodology can bring to the table -- after that it's about finding and keeping a competant staff who understand the value of what they're doing.]
You are so utterly right. The key idea is "people over process". I've rather have 5 great people with any old process, than 25 mediocre people with the perfect process.
[look at the console gaming industry for tips]
I have always been impressed with the gaming industry for this reason. Sometime people erroneously think of game programming as being somehow less "heavy duty" than business apps, etc. But games are usually under incredible schedule pressure (for vital marketing reasons) yet also need to ship very few bugs, because buyers are prone to return a game that doesn't work, not become a source of upgrade revenues.
[not the fake customer on your XP team, the real customer holding the checkbook]
XP says to have the real customer. If you have a fake customer, it's not "pure" XP. Many people who like XP but can't get a real customer use a "proxy customer", but they (hopefully) admit that they aren't really doing XP per se, just something similar to it.
You are of course 100% right that satisfying a fake customer is irrelevant if you don't satisfy the person with the checkbook! In my mind, customer equals check-writer.
[There's a great deal of XP fundamentalism out there, mostly on the part of development managers]
That actually doesn't match my experience at all. I see many developers who are very excited about XP, but many development managers seem to like some of the ideas but be *far* from "fundamentalists" about it. Rather they want to immediately disregard major portions of it, typically.
[about as atomic as you can get in an asynchronous system]
I've built a number of asyncronous systems, and agree they can be challenging. I do believe it makes testing even more important. If I was building the system you describe, I would probably insist on testing that piece.
Regarding choosings unit tests, the frequent advice is to test everything that could possibly break, which is pretty vague - but it definately includes this async beast.
[Well, I can't point to any project that managed to successfully implement "pure" XP]
[didn't have enough staffing to constantly pair program] etc.
My last project didn't do RUP. And it didn't do Scrum, although we no doubt did bits and pieces of each. I don't use it as an example of either of those methods succeeding or failing.
Your projects didn't do XP, it did bits and pieces of it, omitting large important portions. So why would it indicate anything about XP? Because the people talked about XP a lot while they did something different?
[The Cult of XP claims to have the one right and true solution]
I've read thousands of messages on the XP mailing list, I've been to an XP conference, I've read a few of the books, and I've seen presentations by most of "big names". In the process, I have not seen such claims.
Who is making this claim?
Oops, posted early. Other strange things:
[asynchronous input from five different sources, where that input consists of five different complex packages]
I've found that it makes a lot more sense to focus on testing the hard stuff, like this, than simple things like the ones you mentioned. By the way, it's also quite useful (totally apart from XP) to decompose such a beast into pieces you can test effectively.
[so don't sacrifice your project and your customer on the altar of XP]
I've never heard of this happening. Can you point to any project which did XP (most or all of it, not just talked about it) and resulted in an unhappy customer for that reason?
I've mostly seen people do little bits of XP (ignoring most of it), fail, and blame XP. A typical story is "we did XP, but we didn't do much testing, we didn't pair program, we didn't have a customer on site, we didn't integrate very often, we didn't track our progress, and our project went badly, therefore XP is bad". Weird.
I found a couple of things strange in this post:
[unwillingness to sacrifice key features in order to make time to build unit tests for every radio button]
Personally, I do test-intensive coding because it helps me go faster (build more functionality per unit time). If it didn't, I wouldn't. I also don't see the point in unit testing a radio button.
Rural areas are usually cheaper primarily in terms of housing expenses, and restaurants. However, a great many things in life cost generally the same in rural areas as anythere else:
Cars
Gas
Many kinds of insurance
Computer software and hardware
Vacations
etc.
[Low gas prices today are instrumental in ensuring continued dependency tomorrow]
:-)
Ah... so if prices are high, it must be because of a conspiracy. If prices are low, it must be because of a conspiracy
Conspiracies might or might not exist. But I don't think that high or low prices per se are evidence of anything.
The comment about Enron execs and bonuses is right on, although it has nothing to do with the industry they are in. It often appears that large publicly traded companies are operated more for the benefit of top management than for the benefit of the owners (stockholders). As someone who owns some stock but it not an executive at a large firm, this annoys me.
[they'd be propping up prices to stop them from falling so low]
Perhaps the conspiracy theory needs to be amended with an explanation that while the conspirators are clever enough to operate a vast network of wrongdoing without detection, they just aren't smart enough to figure out how to actually make oil prices go up. If I was one of these theoretical Big Oil execs with a bunch of politicians on the payroll, I'd fire them, they're doing a lousy job. I put gas in my car the other day for 98 cents a gallon.
On the other hand, perhaps we should consider the possibility that George W. just might have things on this *other* than oil companies.
(Cynicism follows)
To some extent, the purpose of a smokestack is to get the junk that comes out of it to disperse widely, over lot of people far away who can't do much about it, rather than locally, over the people close enough to it to be able to do something about it politically.
This is the kind of idea (put two known good ideas, mix in "internet", boom!) that seems like it would have a bogus patents on it.
I've only been to NJ once, and wondered this:
Are you suppossed to tip the gas station attendant?
Often, the cable modem provider's objection is *not* to the bandwidth, but merely to running any kind of server.
10 GB/month of Napster/whatever: OK
1 MB/month of web server: not OK
The error addition for civilian use was phased out a couple of years ago. There was probably Slashdot discussion about it at the time.
[know how Basic Authentication works before hosting web sites]
... and know that it's a wholly inadequate way of "protecting" credit card numbers!
[Not only does my employer need to find someone who can code in C, C++, Java, Perl, Python, shell script, and assembler]
You are certainly right in the extreme case, but this is often overdone. If your employer is not hiring people who can learn a bit of Python when they need it, perhaps they should hire different people. If you can save a lot of time and money why adding a second language to a project, it may well be worthwhile. Adding the 5th language very likely is never worth it.
You are right, but this is sometimes taken too far. Some companies / managers have a wildly over-inflated idea of the effort of switching to new tools or new languages.
Indeed, you are right about both the post and the drives.
However, there are lots of situations for which people have a need for very large storage, but don't have a need for 99.99999% uptime, amazing reliability, etc., and you can now buy the former for much less cost than the latter. Three years ago, if you needed terabyte, you had to spend a huge amount on an EMC or whatever; now, you only have to spend that if you need a huge amount *and* you need great reliability.
The world keeps changing, too. In a few more years, if you need a terabyte, that will be one hard drive. If you need higher availability, you'll need just a normal RAID subsystem, which is included in many servers and is far cheaper than an EMC storage system.
I remember looking at a 10 gig storage subsystem for a document imaging application some years ago. It was an optical disk system with a robotic arm for swapping a library of disks, $20K+ Today my notebook has that much space.
I haven't the fainted idea why my post was moderated 'troll'... I certainly did not intend it as such.