The LDS Church has a very active worldwide charity organization that has provided over $1 billion in humanitarian aid (cash, goods, services) in the past 25 years. The LDS Church itself covers all administrative costs, so 100% of any donation goes to actual use. Here are some of the projects currently being funded.
Might as well close the comments now.
Go look up Robert Austin's book on measurements and management. Read it and recognize that you've been given a task that is at best counterproductive and at worst impossible. Dust off your resume, because it may be more than one of you that are getting fired.
The quote above is from Jerry Weinberg, and it is true.
There's an entire brilliant, short book about this problem: Measuring and Managing Performance in Organizations by Robert Austin (1996). It's actually a fairly rigorous, somewhat philosophical work, but it is pretty unrelenting to documenting that, indeed, trying to manage by metrics almost always introduces distortions, which in turn are almost always counter-productive. The problem isn't just with IT, it's with any type of effort that seeks to reward or punish based on metrics.
The only metrics that I've found actually useful in IT are those that are predictive -- for example, aiding to estimate the actual delivery date of a project under development. The metrics that seek to somehow measure "accomplishments to date" solely for the purpose of reward or punishment are always gamed and are almost always useless.
Actually, this cuts both ways. As someone who has acted as an expert witness in a number of lawsuits, I usually want to see the time-sorted e-mail record where relevant, particularly if there are software developers or engineers involved (since they tend to be more, ah, blunt in their statements). I've seen large cases end up settling unfavorably for one side because of a dozen or so internal e-mails that its personnel had written (one I recall said something to the effect of "Why are we charging our client [a large specific sum of money] and delivering them garbage?").
But I fully agree with you as well: document, document, document, whether by e-mail, memo, or letter. If your firm (particularly if you're a software developer/vendor) has never been involved in a lawsuit, there is a tendency to tell yourself, "We'll make this work out; we want to keep the customer happy; we're all grown-ups here," and so rely on verbal assurances or concessions. Then when a lawsuit happens, you have no documentation -- just he-said/she-said testimony -- as to why (and how) the scope changed or the project went over-schedule/over-budget or why certain IP was used or shared or when certain key inventions were developed.
Having built a software development team from scratch for a venture-funded startup, and having done tech vetting for years on consultants, I fully understand the difficulty in determining who's actually talented and who isn't. But I just don't buy that the 'puzzle' approach translates into 'great software engineer'. You may well get a bunch of bright and clever people who are good at puzzles, and it's good to have some folks like that around, but I suspect if everyone is that way, you'll end up with a bunch of engineers trying to out-clever each other -- and that doesn't translate into well-designed and readily-maintained software. IMHO.
That's what my friend and boss Wayne Holder said about Turbo Pascal when I demo'd it for him back when it first came out in the early 80s. It wasn't just that TP was vastly smaller than any other Pascal (C, FORTRAN, etc.) compiler out there, it's that it compiled much, much faster -- in some cases, an order or two of magnitude faster.
The original version of WordPerfect was developed by Bruce Bastian while a grad student at BYU (with Alan Ashton as his faculty advisor). At that time, it was a screen-oriented editor that ran on Data General minicomputers. I know because I shared an office with Bruce during my senior year at BYU (1977-78) and used his existing version of the editor to write several papers for my classes.
I was out to lunch with a group of people and the subject of space exploration came up. Having worked at NASA and LPI (albeit 30 years ago), I expressed my various opinions (e.g., the Shuttle was a mistake and we lost 30-40 years by NASA's hindering private enterprises from space launch systems). The subject of mining asteroids came up; I said that it could provide some long-term benefits, but I would be very, very leery about moving an asteroid into near-Earth orbit, for all the obvious reasons.
That said, moving a 10-meter asteroid into earth orbit carries (IMHO) relatively few risks.
OK, I'm at my laptop, laughing out loud. Well done.
You know, the ones where the character (usually a young, bright geek) rips the cover off the card swipe/keypad unit, shorts a few wires, and opens the door?
"...pick two."
If you're lucky or very good. In lots of projects, you get to pick just one.
I worked for Oasis Systems/FTL Games back in the early 1980s; we had software than ran on the Osborne 1 ("The Word Plus" spelling checker; "Punctuation + Style" grammar checker). In fact, if I remember correctly, we used a utility package running on the Osborne 1 to create most of our other 5.25" CP/M disk formats; there was no standard 5.25" disk format for CP/M, and so we had to create different disks for most different computers running CP/M.
Adam Osborne was actually a columnist for InfoWorld who, after complaining about the state of the personal computing market, decided to take action and start his own computer company. The Osborne 1 was a success (within the scope of the tiny nascent PC market at the time), but he pre-announced the Osborne II too far in advance of being able to ship it, saw his Osborne 1 sales dry up, and ended up having to shut down the company due to lack of cash flow. If you've ever heard anyone refer to "the Osborne effect", that's what they're talking about.
Not much nostalgia here, though -- I'll take my modern laptops, desktops, and digital devices (iPhone 4, iPad 1) over an Osborne any day.
The Atari port happened after I left FTL - and, I'll note, it was a great improvement over the Apple version - but I did do a fair amount of 68000 programming over the next few years. A great processor, and it's a shame that the IBM PC reference architecture wasn't based on it.
I have fond memories of the 6502. I co-designed and did most of the coding for a computer game for the Apple II (Sundog) and so did a lot of 6502 assembly coding. A few years later, I taught assembly language coding to CS students at BYU, and we use 6502-based systems there as well (which was a vast improvement over the IBM 360 assembly + JCL on punch cards that I had to learn on a decade earlier as an undergrad myself).
Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky
