Here's one: you can scan an hundreds of items on a pallet wrapped in shrink wrap, *individually*.
This turns out to be an issue because of an A/R issue called "deductions." This is where the recipient of goods deducts from the invoice saying that they didn't receive everything you claim to have shipped them. With RFID, you can count all items in the pallet right before you ship it.
As a contract programmer often faced with maintenance, grokking the codebase is a waste of customer's time.
I install the application, look at the feature request or bug report, see where the new functionality fits in. Usually in the UI there are identifiable strings.
Use a combination of find, grep to locate the strings, and follow the logic back to locate candidate points for insertion of new functionality. This is where you start to need your brain.
Design your change or fix as if the rest of the codebase doesn't matter, because, well, it doesn't.
On the contrary, if a programmer doesn't know Perl well, then he or she is not qualified to maintain Perl code. Such a programmer is plain and simple, a danger to the code base. Maintenance programming is hard. It means getting into someone else's head enough to make adjustment to their implementation without introducing regressions, or rewriting stuff and losing important features or bugfixes in the process.
So, what do you know, maintenance work is often given to junior engineers, who are as a rule do not have the background and maturity to do maintenance well.
In any event, source code in languages of any reasonable capability, that I don't know, always look like crap to me. Take Scheme: I don't know Scheme, and Scheme code looks like crap. I have learned enough about it to see patterns in the crap, but I still don't know enough to maintain good Scheme code. If I was forced to maintain it my only hope would be to rewrite it to some simpler subset that I do know.
That doesn't say anything about the programmer, the code or the language. It says much more about me.
I'm not saying the code you are maintaining is bad. Maybe it is. But it is hard to tell really good from plain bad unless you're an expert. Edge cases like Obfuscation contest entries aside...
As a professional programmer, easy to learn is somewhere on the list of ideal language attributes but it's nowhere near the top.
I put a language in my bag of tricks if it gives me leverage to solve a wide class of problems in an effective and efficient manner. I ended up liking Perl syntax just fine once I had learned it.
In any event, it's hard to call Perl an unsuccessful language. Based on the breadth and depth of available CPAN modules, and the fact that Perl support is a given on most web hosts, you have to say it's pretty darn successful.
Perl is readable to those that know Perl. I know Perl and I find idiomatic Perl readable.
And "job security" language choices is just as much a problem with regular employees as consultants. As a consultant there's been more then one occasion where I had to go and clean up the mess after some bored employee made an "interesting" language or framework choice presumably to keep themselves interested.
I think Myth #1 is a red herring because no one is positing any Wintel conspiracy here. It doesn't matter much even if there were... Microsoft and Intel with their distinct agendas have caused serious damage to OLPC sales.
I'll grant that I missed your point on #2. I am not all that interested in "Version 2" yet. OLPC needs to have some moderate success at least with the shipping version or there won't be a Version 2. Even though the foundation can go along indefinitely the project could lose momentum and that would be a serious blow.
I don't think the XO is perfect. No computer hardware is. The battery life could be better. But the fact remain that Intel and Microsoft have done damage to the project. That appears to me to have been their (albeit individual) strategies. That's not to say that the apparent new alliance with Intel isn't a good thing. Strategically it probably makes sense.
Nobody actually believes that just putting an unmodified laptop or desktop into a 3rd world kid's hands will automatically produce results. The OLPC is designed from the ground up for non-readers, for collaboration and networking in difficult environments, to be an ebook reader, etc.
If the experiment fails, because the shill laptops from Intel weren't designed to actual requirements, the experiment will be over and it won't be tried again.
I'll just call the Myth #3 wintel cartel a red herring.
On Myth #2, if Intel was really behind the OLPC project, why would they make the Classmate and compete head to head with OLPC? I believe they only got on board once there was a possibility of OLPC to use Intel hardware in the future.
So you're saying on Myth #3 that OLPC should have designed in an untested CPU that isn't on the market till next year?
The Mars Pathfinder project used the 80C85 8-bit low power CMOS technology CPU since it was a tried and tested low power component when the requirements were written. You may know this CPU from the TRS-80 Model 100 laptop released around 1983. It is not good engineering practice to build in the kind of risk implied by designing in unproven components that don't exist yet, when a sufficient to meet requirements, proven alternative exists.
Now the OLPC's screen and mesh networking is the exception that proves the rule. The dual-mode screen and mesh network either did not exist (screen) or were cutting edge (mesh) when they were designed in. Those aspects of the laptop are onest answers to your red-herring Myth #3. Similarly for the Sugar Desktop, an environment designed from the ground up for non-readers, collaboration, and a flash file-system.
The OLPC technology simply runs circles around the competition when it comes to being a more applicable, advanced solution to the problem at hand.
Your mistake is assuming all users have the interest and are qualified or with short-term training can become qualified to install, maintain or extend this "useful software product."
Quite often this is simply not the case. For the vast majority of businesses, IT is a cost center, not a profit center. Businesses will look outside their company for support rather than build up the expertise inside the company. That's why selling support around most any software product above a certain level of complexity, however well designed, can be successful.
-- John.
Yeah bad contractors exist but with good management they get weeded out quickly. With bad management, just as with problem employees, folks can fly under the radar for a while.
If the person lasted very long in that role, you have to wonder about what management was doing as far as checkpoints and milestones.
That said it sounds like there may have been an issue of expecting the contractor to act like a regular employee. A contractor determines method and means of how their assigned work is completed. The contractor should not have had to lie about working on another job at the same time, since it is not the other client's concern (unless of course there is a conflict of interest of some sort).
What matters is whether the work gets done when it is needed and within the constraints of the budget. If it wasn't you get rid of the contractor and find another, plain and simple.
Employment is at-will. Anyway, businesses come and go.
Contracting is the way this industry is going and I think that is a good thing. Billing by the hour engenders more professionalism on both sides of the equation. Normally employers look at young engineers as a safety valve for inability to plan the project. They have no life, so we can wink/nudge them into working way past 40 hours. Billing by the hour, contractors know that they have to produce in the alloted time.
So I wouldn't look at anything that pushes us away from healthy use of contractors as being "a good thing."
We could go back to paper and make their jobs a lot easier. Or just damage the network interface, disk drives, and usb ports. They keyboard and screen while we're at it.
Whoever said IT was supposed to be easy? That's the challenge of IT: to keep the network and desktops functioning, information flowing without impeding people's ability to work efficiently.
Additionally, the comment about portability is hilarious. Laptops are clearly transportable. They can be moved from place to place easily. But true portability is something that has eluded the industry since the Model 100 line went off the market.
License != Contract. I guess you have consideration. What about the offer and acceptance? Do you really have an exchange of promises?
A license is not a contract. It is more a one-sided offer of permission to do something that would, without the license grant, be illegal. A license can have restrictions.
The idea with the GPL is it has restrictions. The logic is that if you don't comply with these restrictions then you never had the right to distribute. And in the case of a copyrighted work, if you redistribute without ownership or a license, and you do it willfully, then you are liable for 3x the statutory damages.
I dunno. Lead developer/architect isn't so bad. Build the role the way you want it... more like the architect from Mythical Man Month... you are really still a developer, but you are able to depend on your team in order to add leverage your own abilities.
It is IMHO a mistake however to call that a "management" role. I don't think you can manage and be the architect at the same time. They are different jobs and you won't have time for both.
My personal acid test as to whether you are really a manager is if you have input on and are responsible for a budget.
Authority must come with accountability, and unless you have input to the budgeting and planning processes, you don't have sufficient authority to be an accountable manager.
The fact that upper management became involved in a 20 faxes per day gateway service would seem to me to be the actual problem there.
Upper management is supposed to be thinking about strategy, not day to day operational decisions. That said, if the choice of management at your level didn't work out, well, accountability falls to those managers for the decision.
The striking thing about all of the distros I've seen is that barring incidental things like packaging systems, KDE or Gnome, etc. they are largely the same. The biggest change I've seen of late is an huge increase in quality of the free-as-in-freedom distros.
But why would you want to invest a large %age of your time making something that well, is already done reasonably well by somebody else.
What would be nice is if the smaller distros start to take a role of really experimenting and breaking the rules.
OLPC is an example of what I'm talking about. They work from requirements, think outside the box and have come up with something truly amazing, something new.
So those slaving away on their boutique distro that looks like the rest, please, find something better to do, like really innovating. That's the only way to make your distro a break-out success anyway.
It's kind of like US presidential candidates. The field starts out pretty wide but you know early on most of them don't have a chance. The fringe candidates should at least make themselves useful, speak the truth and stir things up.
At the end of the day a corporation's primary responsibility is to create shareholder value.
But it is tempting (easy) to take far too simplistic a view of that.
Take environmental policy, for example. The simplistic "bottom line" thinking is screw the environment. But it is short term, will upset many stakeholders, and eventually, the government will come in and regulate. All those are serious consequences that will affect shareholder value. Where is the balance point?
I think one of Google's selling points is its "Do No Evil" motto, and how they have lived up to it so far. If they lose that corporate image and corporate culture, it is a marketing failure for Google in my book.
a) You use exceptions at all. Actually, these are worse than goto since you actually jump right out into some random outer dynamic scope.
b) You exit loops early... break, continue, last, again, redo et al.
My feeling is, there's nothing wrong with goto when it is used methodically to implement missing language features or code patterns (like common cleanup). Also it may be used sparingly during code maintenance to modify program behavior without radically reworking code which has already been tested to working state.
I limit my vintage computing hobby to laptops. The main reason is that each laptop is the pinnacle of engineering in its day. Some aspects of vintage laptops, like battery life, boot time (if any) stand their ground against modern laptops and in important ways surpass them (Model 100 series, Cambridge Z88, NC100, NEC-8500...)
Laptops are easy to store, so you don't have a big physical space issue like you do with some of the minicomputers and even some micros. Earlier vintage laptops don't require special power supplies, and some run off off-the-shelf alkalines or rechargeable batteries.
Anyway, the place for Model 100 users to find the community is http://club100.org/
Slashdot Mirror
There exist standards for both EPC formats and reader protocols. See EPCGlobal's web site.
-- John.
Actually, there are other advantages.
Here's one: you can scan an hundreds of items on a pallet wrapped in shrink wrap, *individually*.
This turns out to be an issue because of an A/R issue called "deductions." This is where the recipient of goods deducts from the invoice saying that they didn't receive everything you claim to have shipped them. With RFID, you can count all items in the pallet right before you ship it.
-- John.
As a contract programmer often faced with maintenance, grokking the codebase is a waste of customer's time.
I install the application, look at the feature request or bug report, see where the new functionality fits in. Usually in the UI there are identifiable strings.
Use a combination of find, grep to locate the strings, and follow the logic back to locate candidate points for insertion of new functionality. This is where you start to need your brain.
Design your change or fix as if the rest of the codebase doesn't matter, because, well, it doesn't.
-- John.
On the contrary, if a programmer doesn't know Perl well, then he or she is not qualified to maintain Perl code. Such a programmer is plain and simple, a danger to the code base. Maintenance programming is hard. It means getting into someone else's head enough to make adjustment to their implementation without introducing regressions, or rewriting stuff and losing important features or bugfixes in the process.
So, what do you know, maintenance work is often given to junior engineers, who are as a rule do not have the background and maturity to do maintenance well.
In any event, source code in languages of any reasonable capability, that I don't know, always look like crap to me. Take Scheme: I don't know Scheme, and Scheme code looks like crap. I have learned enough about it to see patterns in the crap, but I still don't know enough to maintain good Scheme code. If I was forced to maintain it my only hope would be to rewrite it to some simpler subset that I do know.
That doesn't say anything about the programmer, the code or the language. It says much more about me.
I'm not saying the code you are maintaining is bad. Maybe it is. But it is hard to tell really good from plain bad unless you're an expert. Edge cases like Obfuscation contest entries aside...
-- John.
As a professional programmer, easy to learn is somewhere on the list of ideal language attributes but it's nowhere near the top.
I put a language in my bag of tricks if it gives me leverage to solve a wide class of problems in an effective and efficient manner. I ended up liking Perl syntax just fine once I had learned it.
In any event, it's hard to call Perl an unsuccessful language. Based on the breadth and depth of available CPAN modules, and the fact that Perl support is a given on most web hosts, you have to say it's pretty darn successful.
-- John.
Perl is readable to those that know Perl. I know Perl and I find idiomatic Perl readable.
And "job security" language choices is just as much a problem with regular employees as consultants. As a consultant there's been more then one occasion where I had to go and clean up the mess after some bored employee made an "interesting" language or framework choice presumably to keep themselves interested.
-- John.
I think Myth #1 is a red herring because no one is positing any Wintel conspiracy here. It doesn't matter much even if there were... Microsoft and Intel with their distinct agendas have caused serious damage to OLPC sales.
I'll grant that I missed your point on #2. I am not all that interested in "Version 2" yet. OLPC needs to have some moderate success at least with the shipping version or there won't be a Version 2. Even though the foundation can go along indefinitely the project could lose momentum and that would be a serious blow.
I don't think the XO is perfect. No computer hardware is. The battery life could be better. But the fact remain that Intel and Microsoft have done damage to the project. That appears to me to have been their (albeit individual) strategies. That's not to say that the apparent new alliance with Intel isn't a good thing. Strategically it probably makes sense.
But OLPC must sell what they've got.
-- John.
No, it matters a lot.
Nobody actually believes that just putting an unmodified laptop or desktop into a 3rd world kid's hands will automatically produce results. The OLPC is designed from the ground up for non-readers, for collaboration and networking in difficult environments, to be an ebook reader, etc.
If the experiment fails, because the shill laptops from Intel weren't designed to actual requirements, the experiment will be over and it won't be tried again.
-- John.
I'll just call the Myth #3 wintel cartel a red herring.
On Myth #2, if Intel was really behind the OLPC project, why would they make the Classmate and compete head to head with OLPC? I believe they only got on board once there was a possibility of OLPC to use Intel hardware in the future.
So you're saying on Myth #3 that OLPC should have designed in an untested CPU that isn't on the market till next year?
The Mars Pathfinder project used the 80C85 8-bit low power CMOS technology CPU since it was a tried and tested low power component when the requirements were written. You may know this CPU from the TRS-80 Model 100 laptop released around 1983. It is not good engineering practice to build in the kind of risk implied by designing in unproven components that don't exist yet, when a sufficient to meet requirements, proven alternative exists.
Now the OLPC's screen and mesh networking is the exception that proves the rule. The dual-mode screen and mesh network either did not exist (screen) or were cutting edge (mesh) when they were designed in. Those aspects of the laptop are onest answers to your red-herring Myth #3. Similarly for the Sugar Desktop, an environment designed from the ground up for non-readers, collaboration, and a flash file-system.
The OLPC technology simply runs circles around the competition when it comes to being a more applicable, advanced solution to the problem at hand.
-- John.
Your mistake is assuming all users have the interest and are qualified or with short-term training can become qualified to install, maintain or extend this "useful software product." Quite often this is simply not the case. For the vast majority of businesses, IT is a cost center, not a profit center. Businesses will look outside their company for support rather than build up the expertise inside the company. That's why selling support around most any software product above a certain level of complexity, however well designed, can be successful. -- John.
Yeah bad contractors exist but with good management they get weeded out quickly. With bad management, just as with problem employees, folks can fly under the radar for a while.
If the person lasted very long in that role, you have to wonder about what management was doing as far as checkpoints and milestones.
That said it sounds like there may have been an issue of expecting the contractor to act like a regular employee. A contractor determines method and means of how their assigned work is completed. The contractor should not have had to lie about working on another job at the same time, since it is not the other client's concern (unless of course there is a conflict of interest of some sort).
What matters is whether the work gets done when it is needed and within the constraints of the budget. If it wasn't you get rid of the contractor and find another, plain and simple.
-- John.
Repeat after me:
There is no such thing as a permanent job.
Remove that phrase from your lexicon.
Employment is at-will. Anyway, businesses come and go.
Contracting is the way this industry is going and I think that is a good thing. Billing by the hour engenders more professionalism on both sides of the equation. Normally employers look at young engineers as a safety valve for inability to plan the project. They have no life, so we can wink/nudge them into working way past 40 hours. Billing by the hour, contractors know that they have to produce in the alloted time.
So I wouldn't look at anything that pushes us away from healthy use of contractors as being "a good thing."
Of course, I'm a contractor...
-- John.
The Cambridge Z88 is a pretty nice vintage laptop. Not a QL and it doesn't fold up, but same DNA.
-- John.
We could go back to paper and make their jobs a lot easier. Or just damage the network interface, disk drives, and usb ports. They keyboard and screen while we're at it.
Whoever said IT was supposed to be easy? That's the challenge of IT: to keep the network and desktops functioning, information flowing without impeding people's ability to work efficiently.
Additionally, the comment about portability is hilarious. Laptops are clearly transportable. They can be moved from place to place easily. But true portability is something that has eluded the industry since the Model 100 line went off the market.
-- John.
Hmm... when was the last time you were educated by the big media companies about a really good band?
Personally I hear more about good music via NPR or via my "social network" real-world or online.
I'll admit that the big media companies are good at marketing pop music to teenie boppers.
-- John.
License != Contract.
I guess you have consideration. What about the offer and acceptance? Do you really have an exchange of promises?
A license is not a contract. It is more a one-sided offer of permission to do something that would, without the license grant, be illegal. A license can have restrictions.
The idea with the GPL is it has restrictions. The logic is that if you don't comply with these restrictions then you never had the right to distribute. And in the case of a copyrighted work, if you redistribute without ownership or a license, and you do it willfully, then you are liable for 3x the statutory damages.
http://www.informit.com/articles/article.aspx?p=212176&seqNum=3&rl=1
That's the theory anyway. I guess we'll see.
-- John.
I dunno. Lead developer/architect isn't so bad. Build the role the way you want it... more like the architect from Mythical Man Month... you are really still a developer, but you are able to depend on your team in order to add leverage your own abilities.
It is IMHO a mistake however to call that a "management" role. I don't think you can manage and be the architect at the same time. They are different jobs and you won't have time for both.
My personal acid test as to whether you are really a manager is if you have input on and are responsible for a budget.
Authority must come with accountability, and unless you have input to the budgeting and planning processes, you don't have sufficient authority to be an accountable manager.
-- John.
The fact that upper management became involved in a 20 faxes per day gateway service would seem to me to be the actual problem there.
Upper management is supposed to be thinking about strategy, not day to day operational decisions. That said, if the choice of management at your level didn't work out, well, accountability falls to those managers for the decision.
-- John.
Yeah 17 hours is the conservative number.
However I do run Remem upgrade http://www.istop.com/~sadolph/remem_home.html
which uses up some of the power.
With my 4 D-Cell power "pillow" in the backpack I supposedly can get 200 hours... I've never had to replace the batteries in that though.
-- John.
I think it's ridiculous that the battery life on such a machine is only 3 hours.
On a completely solid state machine? Please...
Guess my TRS-80 Model 100 hobby is still safe (17 hours of battery life on 4 AA's)
-- John.
The striking thing about all of the distros I've seen is that barring incidental things like packaging systems, KDE or Gnome, etc. they are largely the same. The biggest change I've seen of late is an huge increase in quality of the free-as-in-freedom distros.
But why would you want to invest a large %age of your time making something that well, is already done reasonably well by somebody else.
What would be nice is if the smaller distros start to take a role of really experimenting and breaking the rules.
OLPC is an example of what I'm talking about. They work from requirements, think outside the box and have come up with something truly amazing, something new.
So those slaving away on their boutique distro that looks like the rest, please, find something better to do, like really innovating. That's the only way to make your distro a break-out success anyway.
It's kind of like US presidential candidates. The field starts out pretty wide but you know early on most of them don't have a chance. The fringe candidates should at least make themselves useful, speak the truth and stir things up.
-- John.
Hmm... then the judge is in good company: Don Knuth does his emailing offline too...
Turns out he's no slouch when it comes to technology.
At the end of the day a corporation's primary responsibility is to create shareholder value.
But it is tempting (easy) to take far too simplistic a view of that.
Take environmental policy, for example. The simplistic "bottom line" thinking is screw the environment. But it is short term, will upset many stakeholders, and eventually, the government will come in and regulate. All those are serious consequences that will affect shareholder value. Where is the balance point?
I think one of Google's selling points is its "Do No Evil" motto, and how they have lived up to it so far. If they lose that corporate image and corporate culture, it is a marketing failure for Google in my book.
-- John.
a) You use exceptions at all. Actually, these are worse than goto since you actually jump right out into some random outer dynamic scope.
b) You exit loops early... break, continue, last, again, redo et al.
My feeling is, there's nothing wrong with goto when it is used methodically to implement missing language features or code patterns (like common cleanup). Also it may be used sparingly during code maintenance to modify program behavior without radically reworking code which has already been tested to working state.
-- John.
I limit my vintage computing hobby to laptops. The main reason is that each laptop is the pinnacle of engineering in its day. Some aspects of vintage laptops, like battery life, boot time (if any) stand their ground against modern laptops and in important ways surpass them (Model 100 series, Cambridge Z88, NC100, NEC-8500...)
Laptops are easy to store, so you don't have a big physical space issue like you do with some of the minicomputers and even some micros. Earlier vintage laptops don't require special power supplies, and some run off off-the-shelf alkalines or rechargeable batteries.
Anyway, the place for Model 100 users to find the community is http://club100.org/
-- John.