Bah. It's pretty clear that population will peak at about 10B, within about 30 years. This is based on already-existing trends; much of the industrial world is already at negative growth, and we've already passed "peak child" (maximum number of babies per woman) and are basically at replacement rate worldwide, though population will continue to grow because the prior growth makes the age distribution "bottom-heavy", so we'll keep growing until we fill out the populations of older people.
After that we'll probably begin a gradual, slow decline in population not due to resource constraints but rather because of rising average female education levels and workforce participation.
Resources will diminish, sure, but we'll also get much more efficient with our use of those resources -- we'll have to, and there is lots of room to economize, while still increasing our average standard of living. In particular, we've barely even begun to tap the efficiencies provided by information technology and massive internetworking. I do most of my meetings via videoconference today; give it another 20 years and unless your work is hands-on there will be no reason whatsoever to commute to work. Consider the extension of petroleum resources that would be enabled if 75% of automobile commuting and an even higher percentage of business air travel were eliminated.
Self-driving cars will be an unbelievable resource saver in the transportation space as well. Not only will families that currently have two cars need at most one because commuting won't be required, but they won't even need one. They'll just call an automated taxi whenever they need to go somewhere. Hit a button on your phone and a car shows up in 30 seconds, drives you where you need to go and drops you off for substantially less cost than what you pay per mile owning your own vehicle today. Consider a world in which we need only 1/10th of the number of automobiles -- even assuming the same level of local travel -- because the cars that exist are nearly always in motion rather than being parked most of the time. Eliminate nearly all of the parking lots and driveways and garages and suburban sprawl becomes considerably more compact and efficient, even without shifting to high-density housing, which means even less need of automobile travel, because walking and cycling are more feasible.
Continuing the transportation theme, consider the efficiencies to be gained by shifting from gasoline to electric vehicles. Granted that this requires some improvements in battery technology, but there are a lot of them on the horizon. EVs can and should be lighter, simpler and cheaper (assuming cheaper batteries than we have now) than gasoline cars. Oh, toss in self-driving cars that dramatically reduce accident rates and we can remove a thousand pounds of safety equipment from each of the vehicles as well.
Altogether, we're on the cusp of a number of changes that will reduce the cost and footprint of transportation by at least an order of magnitude, and perhaps two -- without reducing wealth or quality of life. In fact, travel may well increase, but it will nearly all be leisure travel, and still cost far less in total that the resources we devote today. And that's just transportation. There are similar huge efficiency gains to be had in nearly every industry.
By the end of this century, we'll all be wealthier than we are now, though I can't imagine the difference will be as large as the gains of the last century, but maybe that's just because I lack imagination. The population may or may not be as large as it is now, but it'll be on a gentle decline because there will be less need of children, rather than because we can't afford them.
The way to make it better, which, I believe, is what Obama is saying, is to make it even easier for them to stay and become highly-paid, productive citizens.
1. It doesn't matter if a corporation just sits on the cash, sitting on the cash increases the market value of the corporation, which results in asset value increases for those holding the stock, and capital gains when it's sold. Corporations holding cash and stockholders holding stock can temporarily tie up the income, but eventually the stock changes hand, and eventually the cash is spent.
2. If the corporation sends the money overseas and it gets spent there (e.g. to pay employees), it will be taxed there.
3. I don't see how job outsourcing is even relevant.
why isn't this income (capital gains) then taxed as high as 'ordinary' income, or, as the comparison is about spot-on, as high as lotto winnings?
The theory is that taxing gains at a lower rate encourages investment and increases tax revenues by increasing GDP growth. I don't personally have a position one way or another on that question. I think that's a question to be answered with data, and I don't know what the data says.
I prefer for corporations to pay their share... so I have to pay less
Do you work for a corporation, or are you supported by someone who works for a corporation? Do you buy things from corporations, or made by corporations? If so, you fund whatever taxes the corporations pay. If not, you must live in a shack in the mountains and use someone else's computer and Internet connection.
All taxes are ultimately taxes on individuals, because all money ultimately belongs to individuals -- even money held by corporations, whatever their legal personhood, because corporations have owners (in fact, US corporations are mostly owned by middle-class Americans). Corporate taxes are just one of many ways governments try to hide the taxation of individuals from those individuals. It's one of the more successful schemes, since so many individuals not only don't complain about being taxed in this way, but even applaud it and demand to be taxed harder.
Taxes are fine, and necessary, but they should be assessed openly and directly, with end-of-year totals being delivered to every taxpayer so that everyone sees exactly how much they personally paid, ideally with some breakdown of how the money was spent. In the event the government runs a deficit, this report should also include an accounting of the individual's estimated portion of the debt. This would enable us to have a more rational, informed, discussion of the costs and benefits of taxation and spending.
Honestly it is amazing how the crap-fest volume approaches infinity immediately after a rare tweet from Mr. Musk. Who is a guy who actually accomplishes things.
Derision has become the normal slashdot attitude towards people who do things. Particularly if they make large amounts of money doing things.
Moreover, the idea that there are actually 343M active users on G+ flies in the face of everything most of us know about the network, which is that the place is a virtual ghost town.
That depends entirely on who you circle or -- more importantly -- has circled you. It appears to me that the vast majority of Google+ posts are not public.
Personally, my stream contains far more content than I can possibly keep up with. Only about a third of it is from personal friends or family, though. Most is from communities I'm a member of and various other people and projects I follow. If you're interested in Linux, for example, all of the major developers post on Google+.
For my usage, I much prefer Google+ to FB. The volume of content on Google+ is lower (but still more than I can actually read), but the quality is much higher. I dumped my FB account a while ago. However, my wife has maintained hers because there are a lot of people in our families who aren't on G+ so she uses FB to follow them, and tells me what I need to know. If I couldn't get that second-hand, I'd probably have to use both.
It seems as if this is what a lot of "Google+ users" actually are - people who use other google products which have Google+ integration that they trick people into activating
Note that the report data supposedly does not come from the companies who own the products being measured. Unfortunately the methodology isn't described. Does anyone know how the "Global Web Index" data is collected? Most methods I can think of would not be fooled by the kind of "fake" engagement you're describing.
You know you've got a killer app when a demo causes members of your target market to realize how much your software is going to change their lives, and they burst into tears.
Especially when your target market is a bunch as prone to emotional outbursts as accountants.
If you have the ability, try the big names. Google, Apple, Microsoft, etc. They're always hiring and they don't care about age, just ability. Of course, their standards are high, and even for people who meet them it's somewhat random if you get an offer. Still, definitely worth a shot. Make sure you're prepared, though: I suggest working your way through one of the programming interview question books first. People with lots of experience tend to do very well at that stuff once they do a little refresher, but they (we!) do need a refresher.
I work for Google, am in my mid-40s, and work with a bunch of people who are quite a bit older than I am (and a lot who are quite a bit younger as well).
It's probably obvious and I'm just being stupid, but I can't think what you could possibly break by setting all perms to 777. Yeah, you'll mark a bunch of non-executable files as executable, but nothing should be trying to execute them anyway. There may be a few files (like/etc/passwd|shadow) which some components might refuse to use if they're world-readable, I suppose...
Any idea what broke?
BTW, my similar story: I purchased a NeXT machine in 1991. It came with a 110 MB hard drive, which wasn't a lot of space even then. I quickly ran out and so I started looking for stuff that I could delete to save space. I found that a big chunk of my disk space was consumed by ".so" files in various "lib" directories. Clearly they were files that I never used, so I deleted them. The system kept running, for a little while...
Rewriting code because it's ugly and nasty is almost always a bad idea. Leave it alone. Focus your code improvement efforts on new code, preventing more of the badness from being created. And even there, if the ugliness is deeply ingrained in the culture you have to start small. If you're given a huge pile of ugly code to review, start by asking for small improvements. Extract a set of subroutines from a 400-line method. Factor a God class into a Lesser Deity class plus a couple of support classes, that sort of thing.
If you're the lone voice of experience among a group of young developers, you may have to teach by example, at least to begin with. Have them review your code -- because yours can also be improved -- and along the way they'll learn some things.
You can also start to develop a culture of code excellence. Organize some lunch study sessions in which you study some good books as a group -- Design Patterns, Refactoring, Test-Driven Development, etc. Don't make these mandatory (assuming you're even in a position to do so), but it's very likely there are a few developers who are interested in improving their skills and learning cool new things. See if you can organize a committee of people who are interested in better code to propose other ideas to create a culture of healthy code.
This is all a lot easier if you're in a bigger shop, of course. If there are only three of you and the other two think you're interest in code quality is silly, and management doesn't care, your best bet is to suck it up and live with it or find a new job.
I have this image of vicious eels guarding women's marital fidelity, ready to jump out and bite any unauthorized entrants where it hurts most. Not sure why you call them "social", though. Seems downright anti-social to me.
In my 23-year career I've worked on all sorts of codebases, open and closed. My experience is that horrible code is common everywhere and great code is rare everywhere, but on average open source code is significantly better than closed code.
Maybe authors of horrible code are too ashamed to let anyone see it?
There's some of that, I think, but I think it's a second-order cause. The bigger cause, IMO, is that open source software is rarely deadline-driven.
Maybe open source is totally pointless if nobody can actually _read_ the source code, even if they have a copy, so if your code is truly bad, making it open source is just a waste of time? (Obviously if you take GPL'd code and add your own horrible code to it, open sourcing it can be a legal requirement; it is still pointless).
Yes, I think there is a Darwinian selection process which tends to push bad open source code to the bottom of the pile. This is a good point. There may be just as much of it, but what people tend to hack on and use is the more readable, easier-to-modify code.
I find Code Collaborator (CC) is a great too for reviewing code.. However, you should still sit in a room to discuss the code and use CC for capturing the notes.
I disagree. I find having everyone in a room creates two problems. First, merely having to schedule meetings reduces the number of code reviews that can be done, which increases the amount of code that you try to cover in a given session. It also doesn't allow reviewers to easily do research on related issues to make their commentary more informed. The result is that the reviews are much less detailed. Second, the personal interaction creates more opportunity for emotion to get involved.
Asynchronous reviews are more time-efficient and less emotional. I submit a commit for review, you look at the diff in a nice tool and make comments, I respond with changes, and so on, until we're both happy with it, then I push my commit into the central repository. It works very well. Oh, and a byproduct is that all of the discussion about the code is captured along the way.
With Respect to "Automated testing is a bigger win, but has a steeper up-front cost and the value is harder to quantify".. I think the value is easy to quantify. As your application grows, your automated testing will ensure you have not broken something that was previously implemented. The more use case testing you have the better your end results will be when adding new features and changing code.
What you've (accurately) stated is the reason automated testing is so valuable. What you haven't done is offered any way to quantify the value. You've offered qualitative analysis of the value, not quantitative analysis. Also, even if you can find a good way to measure the value and to assign dollar cost and benefits to it so you can show ROI, much of the ROI of automated testing comes later. Some is immediate, of course. I don't know how many times I've discovered and fixed bugs in my code while writing unit tests, and that win is worth the effort right there -- but it's hard to track. Short of asking developers to not only write unit tests but also to keep detailed logs of what they discovered and fixed, the only way to assess the immediate impact is by observing lower bug counts during QA or later phases, and many shops don't have processes that allow them to establish good baselines for comparison.
Code reviews, however, provide all of the documentation needed to extract a direct measurement of at least part of the value obtained, usually one that on its own justifies the effort.
It sounds to me like this is a group of 2-3 developers who want to improve processes, without (currently) support from the business, which just wants to keep shipping on time. If you can't get management support, you're going to have a hard time, so that's the place to start.
If your management doesn't understand the concept of Technical Debt and how it's costing the company time, money and reducing your agility and competitiveness, that's where you need to start. How to go about educating them is something that you're going to have to figure out for yourself, since you know the people and the context, but I'll give you a warning: people don't like to be told they don't know their business. If you try to approach it like that, you're very unlikely to be successful. And, frankly, unless the group trying to initiate the change is already among the top performers, and has a track record of successfully delivering, you're unlikely to be successful no matter how you go about it. So you first need to get the guys the management perceives as being their top contributors on board.
Still, if you can get the conversation started in the right way, technical debt is a concept that business people can easily grasp, because it so closely parallels the notion of financial debt. For that matter, you should make sure you understand it thoroughly as well, including the fact that it often makes perfect sense to take on technical debt in exchange for a business advantage which is likely to have sufficiently-large rewards. Never forget that the purpose of the code is to generate revenues, not to appeal to your sense of aesthetic purity.
But, technical debt slows progress and massively increases the financial impact of bugs. The interest will be paid -- there's no avoiding it or deferring it -- and as the debt grows it becomes a burden which sucks up all resources. If you can get your management to understand and agree on that, you've won, as long as you don't screw it up.
To avoid screwing it up, do not embark on a massive development process re-engineering effort. If you do, you'll fail. You'll delay the next release, cost the company large amounts of money and customer goodwill and completely undermine everything you said.
Instead, figure out what one thing you can change which will have the most immediate significant and measurable impact. Do that, show the benefit, then move on to the next incremental improvement. This is hard. It requires you to not only figure out what will help the most, but also how to measure the before and after states, and to ensure that your measurements won't be gamed or encourage counterproductive behavior. Also, spend a lot of time thinking hard about how to make the change in a way that will have the lowest negative impact on productivity -- because anything you change is going to hurt at least a little, in the short term.
Though you need to look at your own situation, my prediction is that the thing that will do you the most immediate good is code reviews. Automated testing is a bigger win, but has a steeper up-front cost and the value is harder to quantify. With a little care, it's easy to document the financial benefits of code reviews. But to make them work, you first need good code review tools -- sitting around a table with printouts wastes everyone's time and rarely accomplishes anything. Spend the time to find a good code review tool that you can integrate into your workflow, set it up, test and validate it and be sure that it's going to work well before you ask people to use it. Note that this is all a lot of work, and unless management is extremely enthusiastic you'll probably have to do a lot of it during evenings and weekends.
Once you have it working for a while go back and pull out a bunch of reviews and take some time to carefully analyze what kinds of bugs were identified and fixed in the review process, and try to estimate what it would have c
Personally I wouldn't want my code maintained to levels I've come to expect from open source "standards".
In my 23-year career I've worked on all sorts of codebases, open and closed. My experience is that horrible code is common everywhere and great code is rare everywhere, but on average open source code is significantly better than closed code.
I thought we were talking about the benefits of putting solar cells on the vehicle...
Putting solar panels on the car roof is not mentioned in the post you replied to.
The second sentence of the post I responded to:
Assume you could cover the entire top surface(s) of a small car with solar panels
;-)
In a previous reply I said at one tyme employers in CA were offering recharging stations as a fringe benefit to employees. For those whose employers don't offer that charging from the gird may be viable. Now if I had solar panels on my roof, with or without, grid enter-tie I wouldn't mind charging my EV batteries at night. But then again I'd like to have a wind genie, as part of a hybrid energy system, as well. The grid would only be there as a backup.
Not being dependent on the grid would be cool, but charging from the grid isn't just viable, it's a good deal. I estimate that I would save about 80% of my "fuel" costs vs driving a gasoline burner even if I charged at home. In practice I mostly only charge at work, so I save closer to 100% of my fuel costs. Of course, the EV is more expensive up front, but when I worked out the numbers I found that the break-even period was about 5 years even without any tax credits. With the $13K of tax credits available (where I live, in Colorado), it's a no-brainer -- assuming you don't need to drive more than about 100 miles per day.
I thought we were talking about the benefits of putting solar cells on the vehicle...
I actually have been looking into installing solar panels on my home, though I probably won't charge my car from them (directly or time-shifted via the grid) because I charge my car pretty much entirely at work, from the chargers provided by my employer (Google):-)
Slashdot Mirror
Bah. It's pretty clear that population will peak at about 10B, within about 30 years. This is based on already-existing trends; much of the industrial world is already at negative growth, and we've already passed "peak child" (maximum number of babies per woman) and are basically at replacement rate worldwide, though population will continue to grow because the prior growth makes the age distribution "bottom-heavy", so we'll keep growing until we fill out the populations of older people.
After that we'll probably begin a gradual, slow decline in population not due to resource constraints but rather because of rising average female education levels and workforce participation.
Resources will diminish, sure, but we'll also get much more efficient with our use of those resources -- we'll have to, and there is lots of room to economize, while still increasing our average standard of living. In particular, we've barely even begun to tap the efficiencies provided by information technology and massive internetworking. I do most of my meetings via videoconference today; give it another 20 years and unless your work is hands-on there will be no reason whatsoever to commute to work. Consider the extension of petroleum resources that would be enabled if 75% of automobile commuting and an even higher percentage of business air travel were eliminated.
Self-driving cars will be an unbelievable resource saver in the transportation space as well. Not only will families that currently have two cars need at most one because commuting won't be required, but they won't even need one. They'll just call an automated taxi whenever they need to go somewhere. Hit a button on your phone and a car shows up in 30 seconds, drives you where you need to go and drops you off for substantially less cost than what you pay per mile owning your own vehicle today. Consider a world in which we need only 1/10th of the number of automobiles -- even assuming the same level of local travel -- because the cars that exist are nearly always in motion rather than being parked most of the time. Eliminate nearly all of the parking lots and driveways and garages and suburban sprawl becomes considerably more compact and efficient, even without shifting to high-density housing, which means even less need of automobile travel, because walking and cycling are more feasible.
Continuing the transportation theme, consider the efficiencies to be gained by shifting from gasoline to electric vehicles. Granted that this requires some improvements in battery technology, but there are a lot of them on the horizon. EVs can and should be lighter, simpler and cheaper (assuming cheaper batteries than we have now) than gasoline cars. Oh, toss in self-driving cars that dramatically reduce accident rates and we can remove a thousand pounds of safety equipment from each of the vehicles as well.
Altogether, we're on the cusp of a number of changes that will reduce the cost and footprint of transportation by at least an order of magnitude, and perhaps two -- without reducing wealth or quality of life. In fact, travel may well increase, but it will nearly all be leisure travel, and still cost far less in total that the resources we devote today. And that's just transportation. There are similar huge efficiency gains to be had in nearly every industry.
By the end of this century, we'll all be wealthier than we are now, though I can't imagine the difference will be as large as the gains of the last century, but maybe that's just because I lack imagination. The population may or may not be as large as it is now, but it'll be on a gentle decline because there will be less need of children, rather than because we can't afford them.
The way to make it better, which, I believe, is what Obama is saying, is to make it even easier for them to stay and become highly-paid, productive citizens.
Oh, on the "financial guild" idea... doesn't work. If you receive value from the corporation (guild), it's income and taxable as such.
1. It doesn't matter if a corporation just sits on the cash, sitting on the cash increases the market value of the corporation, which results in asset value increases for those holding the stock, and capital gains when it's sold. Corporations holding cash and stockholders holding stock can temporarily tie up the income, but eventually the stock changes hand, and eventually the cash is spent.
2. If the corporation sends the money overseas and it gets spent there (e.g. to pay employees), it will be taxed there.
3. I don't see how job outsourcing is even relevant.
why isn't this income (capital gains) then taxed as high as 'ordinary' income, or, as the comparison is about spot-on, as high as lotto winnings?
The theory is that taxing gains at a lower rate encourages investment and increases tax revenues by increasing GDP growth. I don't personally have a position one way or another on that question. I think that's a question to be answered with data, and I don't know what the data says.
I prefer for corporations to pay their share... so I have to pay less
Do you work for a corporation, or are you supported by someone who works for a corporation? Do you buy things from corporations, or made by corporations? If so, you fund whatever taxes the corporations pay. If not, you must live in a shack in the mountains and use someone else's computer and Internet connection.
All taxes are ultimately taxes on individuals, because all money ultimately belongs to individuals -- even money held by corporations, whatever their legal personhood, because corporations have owners (in fact, US corporations are mostly owned by middle-class Americans). Corporate taxes are just one of many ways governments try to hide the taxation of individuals from those individuals. It's one of the more successful schemes, since so many individuals not only don't complain about being taxed in this way, but even applaud it and demand to be taxed harder.
Taxes are fine, and necessary, but they should be assessed openly and directly, with end-of-year totals being delivered to every taxpayer so that everyone sees exactly how much they personally paid, ideally with some breakdown of how the money was spent. In the event the government runs a deficit, this report should also include an accounting of the individual's estimated portion of the debt. This would enable us to have a more rational, informed, discussion of the costs and benefits of taxation and spending.
Honestly it is amazing how the crap-fest volume approaches infinity immediately after a rare tweet from Mr. Musk. Who is a guy who actually accomplishes things.
Derision has become the normal slashdot attitude towards people who do things. Particularly if they make large amounts of money doing things.
How can a tweet infringe copyright? I find it inconceivable that 140 characters could ever do that.
I just tweeted the following: "How can a tweet infringe copyright? I find it inconceivable that 140 characters could ever do that."
Hah! I infringed your copyright. Sue me!
Moreover, the idea that there are actually 343M active users on G+ flies in the face of everything most of us know about the network, which is that the place is a virtual ghost town.
That depends entirely on who you circle or -- more importantly -- has circled you. It appears to me that the vast majority of Google+ posts are not public.
Personally, my stream contains far more content than I can possibly keep up with. Only about a third of it is from personal friends or family, though. Most is from communities I'm a member of and various other people and projects I follow. If you're interested in Linux, for example, all of the major developers post on Google+.
For my usage, I much prefer Google+ to FB. The volume of content on Google+ is lower (but still more than I can actually read), but the quality is much higher. I dumped my FB account a while ago. However, my wife has maintained hers because there are a lot of people in our families who aren't on G+ so she uses FB to follow them, and tells me what I need to know. If I couldn't get that second-hand, I'd probably have to use both.
It seems as if this is what a lot of "Google+ users" actually are - people who use other google products which have Google+ integration that they trick people into activating
Note that the report data supposedly does not come from the companies who own the products being measured. Unfortunately the methodology isn't described. Does anyone know how the "Global Web Index" data is collected? Most methods I can think of would not be fooled by the kind of "fake" engagement you're describing.
You know you've got a killer app when a demo causes members of your target market to realize how much your software is going to change their lives, and they burst into tears.
Especially when your target market is a bunch as prone to emotional outbursts as accountants.
I make this point... if you are so goddamn special with your 10 year degree, come on down and prove it face to face in the jungle
Prove it how? I'm interested in what you think would be proven and in what way.
(I don't have a 10-year degree, though, so maybe I don't count.)
If you have the ability, try the big names. Google, Apple, Microsoft, etc. They're always hiring and they don't care about age, just ability. Of course, their standards are high, and even for people who meet them it's somewhat random if you get an offer. Still, definitely worth a shot. Make sure you're prepared, though: I suggest working your way through one of the programming interview question books first. People with lots of experience tend to do very well at that stuff once they do a little refresher, but they (we!) do need a refresher.
I work for Google, am in my mid-40s, and work with a bunch of people who are quite a bit older than I am (and a lot who are quite a bit younger as well).
chmod'ing 777 kills the setuserid-bit.
Duh. I knew it was something obvious. Thanks.
It's probably obvious and I'm just being stupid, but I can't think what you could possibly break by setting all perms to 777. Yeah, you'll mark a bunch of non-executable files as executable, but nothing should be trying to execute them anyway. There may be a few files (like /etc/passwd|shadow) which some components might refuse to use if they're world-readable, I suppose...
Any idea what broke?
BTW, my similar story: I purchased a NeXT machine in 1991. It came with a 110 MB hard drive, which wasn't a lot of space even then. I quickly ran out and so I started looking for stuff that I could delete to save space. I found that a big chunk of my disk space was consumed by ".so" files in various "lib" directories. Clearly they were files that I never used, so I deleted them. The system kept running, for a little while...
Rule #1: Do no harm.
Rewriting code because it's ugly and nasty is almost always a bad idea. Leave it alone. Focus your code improvement efforts on new code, preventing more of the badness from being created. And even there, if the ugliness is deeply ingrained in the culture you have to start small. If you're given a huge pile of ugly code to review, start by asking for small improvements. Extract a set of subroutines from a 400-line method. Factor a God class into a Lesser Deity class plus a couple of support classes, that sort of thing.
If you're the lone voice of experience among a group of young developers, you may have to teach by example, at least to begin with. Have them review your code -- because yours can also be improved -- and along the way they'll learn some things.
You can also start to develop a culture of code excellence. Organize some lunch study sessions in which you study some good books as a group -- Design Patterns, Refactoring, Test-Driven Development, etc. Don't make these mandatory (assuming you're even in a position to do so), but it's very likely there are a few developers who are interested in improving their skills and learning cool new things. See if you can organize a committee of people who are interested in better code to propose other ideas to create a culture of healthy code.
This is all a lot easier if you're in a bigger shop, of course. If there are only three of you and the other two think you're interest in code quality is silly, and management doesn't care, your best bet is to suck it up and live with it or find a new job.
Damn, this climate change is really getting out of control. It's bad enough that the planet's changing, but the universe?
social morays that kept people faithful
I have this image of vicious eels guarding women's marital fidelity, ready to jump out and bite any unauthorized entrants where it hurts most. Not sure why you call them "social", though. Seems downright anti-social to me.
The word you actually wanted is "moré" :-)
In my 23-year career I've worked on all sorts of codebases, open and closed. My experience is that horrible code is common everywhere and great code is rare everywhere, but on average open source code is significantly better than closed code.
Maybe authors of horrible code are too ashamed to let anyone see it?
There's some of that, I think, but I think it's a second-order cause. The bigger cause, IMO, is that open source software is rarely deadline-driven.
Maybe open source is totally pointless if nobody can actually _read_ the source code, even if they have a copy, so if your code is truly bad, making it open source is just a waste of time? (Obviously if you take GPL'd code and add your own horrible code to it, open sourcing it can be a legal requirement; it is still pointless).
Yes, I think there is a Darwinian selection process which tends to push bad open source code to the bottom of the pile. This is a good point. There may be just as much of it, but what people tend to hack on and use is the more readable, easier-to-modify code.
I find Code Collaborator (CC) is a great too for reviewing code.. However, you should still sit in a room to discuss the code and use CC for capturing the notes.
I disagree. I find having everyone in a room creates two problems. First, merely having to schedule meetings reduces the number of code reviews that can be done, which increases the amount of code that you try to cover in a given session. It also doesn't allow reviewers to easily do research on related issues to make their commentary more informed. The result is that the reviews are much less detailed. Second, the personal interaction creates more opportunity for emotion to get involved.
Asynchronous reviews are more time-efficient and less emotional. I submit a commit for review, you look at the diff in a nice tool and make comments, I respond with changes, and so on, until we're both happy with it, then I push my commit into the central repository. It works very well. Oh, and a byproduct is that all of the discussion about the code is captured along the way.
With Respect to "Automated testing is a bigger win, but has a steeper up-front cost and the value is harder to quantify".. I think the value is easy to quantify. As your application grows, your automated testing will ensure you have not broken something that was previously implemented. The more use case testing you have the better your end results will be when adding new features and changing code.
What you've (accurately) stated is the reason automated testing is so valuable. What you haven't done is offered any way to quantify the value. You've offered qualitative analysis of the value, not quantitative analysis. Also, even if you can find a good way to measure the value and to assign dollar cost and benefits to it so you can show ROI, much of the ROI of automated testing comes later. Some is immediate, of course. I don't know how many times I've discovered and fixed bugs in my code while writing unit tests, and that win is worth the effort right there -- but it's hard to track. Short of asking developers to not only write unit tests but also to keep detailed logs of what they discovered and fixed, the only way to assess the immediate impact is by observing lower bug counts during QA or later phases, and many shops don't have processes that allow them to establish good baselines for comparison.
Code reviews, however, provide all of the documentation needed to extract a direct measurement of at least part of the value obtained, usually one that on its own justifies the effort.
It sounds to me like this is a group of 2-3 developers who want to improve processes, without (currently) support from the business, which just wants to keep shipping on time. If you can't get management support, you're going to have a hard time, so that's the place to start.
If your management doesn't understand the concept of Technical Debt and how it's costing the company time, money and reducing your agility and competitiveness, that's where you need to start. How to go about educating them is something that you're going to have to figure out for yourself, since you know the people and the context, but I'll give you a warning: people don't like to be told they don't know their business. If you try to approach it like that, you're very unlikely to be successful. And, frankly, unless the group trying to initiate the change is already among the top performers, and has a track record of successfully delivering, you're unlikely to be successful no matter how you go about it. So you first need to get the guys the management perceives as being their top contributors on board.
Still, if you can get the conversation started in the right way, technical debt is a concept that business people can easily grasp, because it so closely parallels the notion of financial debt. For that matter, you should make sure you understand it thoroughly as well, including the fact that it often makes perfect sense to take on technical debt in exchange for a business advantage which is likely to have sufficiently-large rewards. Never forget that the purpose of the code is to generate revenues, not to appeal to your sense of aesthetic purity.
But, technical debt slows progress and massively increases the financial impact of bugs. The interest will be paid -- there's no avoiding it or deferring it -- and as the debt grows it becomes a burden which sucks up all resources. If you can get your management to understand and agree on that, you've won, as long as you don't screw it up.
To avoid screwing it up, do not embark on a massive development process re-engineering effort. If you do, you'll fail. You'll delay the next release, cost the company large amounts of money and customer goodwill and completely undermine everything you said.
Instead, figure out what one thing you can change which will have the most immediate significant and measurable impact. Do that, show the benefit, then move on to the next incremental improvement. This is hard. It requires you to not only figure out what will help the most, but also how to measure the before and after states, and to ensure that your measurements won't be gamed or encourage counterproductive behavior. Also, spend a lot of time thinking hard about how to make the change in a way that will have the lowest negative impact on productivity -- because anything you change is going to hurt at least a little, in the short term.
Though you need to look at your own situation, my prediction is that the thing that will do you the most immediate good is code reviews. Automated testing is a bigger win, but has a steeper up-front cost and the value is harder to quantify. With a little care, it's easy to document the financial benefits of code reviews. But to make them work, you first need good code review tools -- sitting around a table with printouts wastes everyone's time and rarely accomplishes anything. Spend the time to find a good code review tool that you can integrate into your workflow, set it up, test and validate it and be sure that it's going to work well before you ask people to use it. Note that this is all a lot of work, and unless management is extremely enthusiastic you'll probably have to do a lot of it during evenings and weekends.
Once you have it working for a while go back and pull out a bunch of reviews and take some time to carefully analyze what kinds of bugs were identified and fixed in the review process, and try to estimate what it would have c
Okay, this is silly, but start with the quote at the top. Second sentence. http://slashdot.org/comments.pl?sid=3397157&cid=42650455
Personally I wouldn't want my code maintained to levels I've come to expect from open source "standards".
In my 23-year career I've worked on all sorts of codebases, open and closed. My experience is that horrible code is common everywhere and great code is rare everywhere, but on average open source code is significantly better than closed code.
I thought we were talking about the benefits of putting solar cells on the vehicle...
Putting solar panels on the car roof is not mentioned in the post you replied to.
The second sentence of the post I responded to:
Assume you could cover the entire top surface(s) of a small car with solar panels
;-)
In a previous reply I said at one tyme employers in CA were offering recharging stations as a fringe benefit to employees. For those whose employers don't offer that charging from the gird may be viable. Now if I had solar panels on my roof, with or without, grid enter-tie I wouldn't mind charging my EV batteries at night. But then again I'd like to have a wind genie, as part of a hybrid energy system, as well. The grid would only be there as a backup.
Not being dependent on the grid would be cool, but charging from the grid isn't just viable, it's a good deal. I estimate that I would save about 80% of my "fuel" costs vs driving a gasoline burner even if I charged at home. In practice I mostly only charge at work, so I save closer to 100% of my fuel costs. Of course, the EV is more expensive up front, but when I worked out the numbers I found that the break-even period was about 5 years even without any tax credits. With the $13K of tax credits available (where I live, in Colorado), it's a no-brainer -- assuming you don't need to drive more than about 100 miles per day.
I thought we were talking about the benefits of putting solar cells on the vehicle...
I actually have been looking into installing solar panels on my home, though I probably won't charge my car from them (directly or time-shifted via the grid) because I charge my car pretty much entirely at work, from the chargers provided by my employer (Google) :-)