Entries Tagged 'technology' ↓
June 24th, 2008 — politics, rant, science, technology
In a recent article, Faux Fox News disclosed that political activists planning to protest at the upcoming Democratic National Convention in Denver will have to contend with the Crap Cannon, a sonic weapon that generates an infrasound frequency causing victims to involuntarily defecate! Supposedly, this weapon generates a brown note, a low frequency sound that causes people to lose control of their bowels due to resonance.
According to Faux Fox News, some activists are scared shitless concerned that the Denver police department is armed with such a diabolical device.
We know this weapon and weapons like it have been used at other large protests before. –Mark Cohen, co-founder of the activist group Re-create 68
There’s just one small fly in their, er, ointment; the existence of the brown note has never been scientifically proven. In fact, this urban myth has even been recently busted on the popular Discovery Channel show Mythbusters.
Still, the concept of such a weapon has seeped into popular culture and has been featured in an episode of Southpark as a sound played in a world wide recorder concert that caused the entire population of Earth to suddenly defecate. In the popular comic strip Transmetropolitan, the main character, Spider Jerusalem, totes a pistol-shaped “Bowel Disruptor” used to defeat and otherwise humiliate his enemies.
It’s almost as if we want the brown note myth to be true.
But what has me rumbling is that Faux Fox News published this story at all. Given their right-wing conservativism and well-known pandering to the lowest common societal denominator, I suppose it’s no wonder they’re gushing over the opportunity to spin a story so that the evil Democrats will be using a defecation weapon on brave protesters. I think their editors are combining their metaphors, throwing something at a fan to see what sticks on the wall.
And it smells like doody.
April 30th, 2008 — irony, software development, technology
I recently purchased a new laptop for work. Of course, I’ve spent a good portion of time cursing Vista (we won’t go into that now) and loading software onto the box.
One of the pieces of software that I needed to load was Microsoft’s .NET 2.0 Software Development Kit — 354 megabytes of software development kit! But I have a fast Internet connection, so I downloaded the file and ran the setup.
No go. While extracting the bundled files, the setup process bombed out, saying one of the CAB files was corrupt. Hmmm…maybe the file was corrupted in transit. So, I download the file…again.
Once again, I run the setup. Again, the process bombs out with the same error message.
On a lark, I fire up Firefox — a very good free browser — and download the file…again. Once again, I run the setup. Lo and behold, the files extract and install successfully!
How ironic is it that Microsoft’s SDK for a core component of their operating system is corrupt when downloaded from their site using their browser, but works when downloaded with an alternative browser.
February 25th, 2008 — rant, software development, technology
I recently blogged about a small software project with which I’m involved that is saddled with using a waterfall project methodology; I have never been a fan of the waterfall method but, on this project, I am being engaged through another consulting company that is providing the project management, so I have no choice. I’ve estimated that the software development portion of the project will entail 120 man hours of effort — a very small project. Yet, for this small 120 hour project, I’ve seen 3 major revisions of project scope documents and four weeks slip by while the project manager attempted to "nail down the requirements" with the client.
Now it appears the client has signed off on the "final" project scope document and is ready to begin the project. So the project manager met with us on Friday to kick off the project and discuss the project plan.
A 105 step project plan!
For a software project that is estimated for 120 man hours.
To paraphrase Churchill, never in the face of human endeavor has so little been tracked by so many to so few.
At this point, the client has many pages of requirements documents and an exhaustive project plan, but not a single line of working software code. The management structure of the project has already consumed more time and effort than the actual development of the project’s ultimate deliverable — working software.
Somebody please explain to me how anyone can still place any value on this style of project management.
February 15th, 2008 — software development, technology
I recently read a very good blog post on More Than a Living in which the author, Rick Turoczy, posits that an artisan is more important than their tools. Seems rather obvious when it’s worded like that, eh?
The author makes an excellent point.
People are quite protective of their “tools.”
Oooh. Tools. They’re oh-so-valuable. Lah-di-dah.
Their software. Their methodology. Their ways of doing things. Little flowcharts. Templates. Processes. Scorecards. Whatever.
The perceived value of these tools is huge.
But what about the actual value?
I’d say that there isn’t much value in the tool, at all.
…
In reality, a tool only becomes valuable by being a tool. By becoming something more in the hands of an artisan to manipulate it.
An artisan can quickly transition to new tools. In the MTL article, the author discusses Toby, an Excel whiz. A spreadsheet is Toby’s tool. Excel may be his choice of paintbrush today, but I’m sure he can very quickly pick up any other spreadsheet program and quickly produce a masterpiece. He is master of financial modeling.
Over the years, I’ve seen technology job postings become extremely tool-specific, e.g. the following required applicant skill set pulled directly from a job listing on dice.com. I’ve edited the layout of the post for reasons of legibility, brevity, and removal of pure BS.
- …
- Experience in Web-based software application development experience to include:
- VB.NET / T-SQL / Reporting Services / JavaScript / XML / HTML / DTS / Classic ASP / HTML / web-based forms
- internet integration server (iis) / active directory (ad) / SQL Server 2003 & 2005, SSIS, Visual Studio Team system.
- Understanding of intranet / extranet development / reverse proxy/Share Point portal / windows Share Point services.
- Understanding of impacts of multiple locations spread out globally connected by wide area network of varying speeds with varying desktop configurations.
- Understanding of multiple language, currency and locality impacts
- Use and development of web services
- Good software development practices including controlled processes and separation of development, test, and production environments.
- …
Contrast these job requirements with the idea of an artisan being more important that their tools. One cause of this type of job posting is the need of headhunters and HR personnel — through no fault of their own — to have a checklist with which to filter candidates without consuming valuable interview time and resources.
But even so, this type of job posting seems peculiar to technical industries. Have you ever seen a job posting for a carpenter that required 2 years experience with a Stanley 22 oz Antivibe Framing Hammer? Of course not.
Given an applicant’s demonstrated competency in my field (programming in my case), I don’t hire based upon experience with specific tools. Instead, I’ve always tried to hire based upon three criteria.
- Motivation. Does the candidate show a history of completing tasks and projects? If presented with a problem, do they truly attempt to solve it? Are they lifelong learners? Do they read technical books and journals? Do they play with new technologies? Is this a profession or merely a job?
Intelligence. How do they solve problems? When presented with a problem, do they latch onto the first solution they dream up, or do they develop and evaluate multiple possible solutions? Are they open to new ideas? How well do they think through the balancing of conflicting ideas, requirements, and solutions?
- Personableness. How well will this person fit on the team? I try to imagine the person on the team and how the other team members will relate with them.
Given the potent combination of motivation and intelligence, a Java programmer quickly becomes a C# .NET expert — or vice-versa; experience with specific tools is nice, but relatively unimportant. But even motivation and intelligence must be balanced with how well the candidate will fit in with a team; even the most talented performer isn’t worth the cost of disrupting your team. Terrell Owens is arguably the best receiver in the National Football League, but he has eventually poisoned the locker room of every team for whom he has ever played.
I would never turn down a top-shelf developer because they didn’t possess experience in a particular toolset.
I don’t hire carpenters because of the type of hammer in the tool belt, but rather their knowledge of construction techniques, materials, and craftsmanship. It was Einstein the artisan that revolutionized physics, not his writing implements and certainly not whatever brand of slide rule he used. Mario Andretti not only won auto races in many different types of cars, but also in many different types of auto races.
If you wanted a portrait done in watercolors, would you rule out a Rembrandt because he primarily worked in oils and engravings? I thought not.
February 12th, 2008 — rant, software development, technology
Drip, drip, drip, drip.
Let’s take a road trip. I want you to drive me to California from South Carolina, but I’m not sure exactly where in California, just somewhere in the southern part of the state. I’ll know it’s the right spot when we get there. I need you to provide me with an extremely detailed itinerary, specifying the exact time and location of waypoints along the route. And you must provide this itinerary by merely consulting a map, you cannot check weather or traffic conditions. In fact, you’re not quite sure when we’ll be making the trip, so you can’t even take into account the season. Now imagine we’ll be using a bus on this trip, and all the passengers will be giving you directions and asking for stops along the way — but you’re not allowed to talk to these passengers before the trip. I still need you to provide a firm timetable and cost estimate for this trip.
This hypothetical trip is an example of a wicked problem - a problem whose requirements and limitations cannot be entirely known before completion.
Drip, drip, drip, drip.
Three weeks ago, my company was presented with a small project that we estimated would take about a man-month to perform. Since that time, we have met with the Business Analyst (BA) on the project three more times, and each time, the requirements have changed and we’ve been asked to re-estimate the project. Moreover, with each estimate, we’re asked to provide more detail and clarification. We have had no direct contact with the ultimate users of the proposed system. During this time, the BA has produced a few versions of a very nice requirements document, but right now, the customer has no working software. Instead, the project is going through an endless loop of analysis paralysis.
If the project had kicked off three weeks ago, it would likely be complete by now. The customer could be using the software and providing feedback to the development team so that the software could be further refined to solve the users’ particular and unique needs.
Drip, drip, drip, drip.
This situation is the inevitable result of the use of the waterfall project management methodology. The benefits of working software are being sacrificed for the illusion of control. I view this as shooting a bullet at the moon; if your assumptions, calculations, and aim are absolutely perfect — and no unforeseen circumstances occur — it just might work. But wouldn’t it be better to embrace change? To build flexibility into your methodology to accommodate change, mistakes, and unforeseen circumstances? Wouldn’t it be better to pilot a projectile to the moon?
To go back to our California trip analogy, instead of creating an extremely detailed itinerary, why not create a general overall goal and timetable with smaller chunks of milestones. For instance, let’s just say our target for the first day is to reach Jackson, Mississippi and spend the night there; we’ll cover a good amount of ground, but we’ll allow for a bit of time to deal with traffic in Atlanta and maybe a bit of weather near Birmingham, Alabama.
We anticipate arriving in Jackson in time for dinner, but if we decide as a group to take a detour to see Stone Mountain outside of Atlanta, we won’t stress about arriving a bit later in Jackson. Conversely, we may breeze through Atlanta and arrive in Jackson in early afternoon. If so, we may decide to keep going and perhaps stay overnight in Vicksburg, overlooking the Mississippi River.
But we will have a goal of getting to California. We will have a general strategy (itinerary) developed from maps and previous experience. And we will have a set of tactics to deal with unforeseen circumstances. Some of those tactics may be mitigating the risk and impact of unforeseen challenges by carrying extra maps or a GPS, cell phones for communication, credit cards for ready access to cash, and most importantly an adventurous attitude willing to embrace change.
The point being that we will drive "within our headlights". We will set short, reasonable goals that we can accurately predict and work to achieve those goals daily. If any of those goals are not met for some reason, they are reassessed and tomorrow’s goals may be adjusted — perhaps we won’t be able to go see the world’s biggest ball of string tomorrow. Who knows, with a more relaxed atmosphere on the bus, everyone might even enjoy the trip.
As stated in the Principles of the Agile Manifesto for Software Development, working software is the primary measure of progress.
Instead I’m reviewing yet another change in the requirements documentation. Three weeks of "planning" and "nailing down requirements" for a 4 week project.
Drip, drip, drip, drip.
January 16th, 2008 — history, irony, random, technology
Uranium ore, that is.
On August 29, 1949, the Soviet Union exploded their first atomic bomb. Needless to say, this created quite a stir in the U.S. which launched a massive bomb building campaign to counter the Soviet threat. American policymakers strategically decided the develop native sources of uranium ore (aka U308) so as not to be dependent on foreign sources. The newly created Atomic Energy Commission (AEC) was designated as the only legal buyer of the ore. For several years, the AEC had already been paying top dollar for the ore, touting it as the energy source of the future. AEC chairman, David Lilienthal, crossed the country telling audiences that a uranium pellet the size of a peanut contained the energy of a ton of coal; holding up a lump of coal, he would tell his audience the equivalent size rock of uranium would heat a large city for an entire winter. With the combination of a successful Soviet atomic bomb test, the Korean War, and the beginnings of the domino theory of the fight against communism, the pressure was on the AEC to develop enough weapons-grade uranium to reduce the USSR to pea-gravel several times over.
In March 1951, the AEC doubled the price it was paying for uranium ore and offered a $10,000 bonus to anyone who developed a productive new mine. The AEC also provided guidebooks and geology reports, built supply roads, and constructed ore processing mills — all in support of uranium miners. A uranium rush occurred in Utah. Moab, Utah went from 500 to 5,000 people virtually overnight. There were stories of prospectors renting planes and throwing out claim stakes in an massive mineral rights grab. Not coincidentally, Moab was the first place in Utah to allow alcohol.
Into this rush came Charlie Steen, an unemployed geologist from Texas, hitchhiking into Utah in 1952. Until this time, most uranium was either found on the surface or in excavated mines. Steen believed the ore could be found using drilling derricks to bore vertically to the ore. Legend has it that, in July 1952, he was down to his last dollar, wearing boots so worn his toes stuck out through holes, when his drill bit broke off in his bore hole. In disgust, he collected his samples from that day and drove home. On the way, he stopped at a service station where a friend had a Geiger counter. Apparently, everyone in Moab had a Geiger counter in those days. When he put the counter on his samples, the needle pegged all the way over. Steen had found a huge vein of uranium ore. His mine eventually produced over $100 million of ore. Steen had his worn-out boots bronzed.
The AEC continued its favorable pricing policies until 1966. By the early 70’s the price of uranium ore had bottomed out. Then came the oil embargo of the 70’s, and ore prices again skyrocketed as America was again electrified about nuclear power as the solution to America’s energy needs. The partial meltdown at Three Mile Island — less than 2 weeks after the opening of the movie The China Syndrome — violently swung the public opinion pendulum against nuclear power. The Nuclear Regulatory Commission (NRC) halted the construction of any new nuclear power plants. In 1986, the Chernobyl reactor explosion occurred, releasing 400 times the radiation as the Hiroshima bomb, further contaminating the reputation of nuclear power.
In the late 80’s the fall of the Soviet Union, was another shock to the price of uranium ore. Ironically, much of the former Soviet Union’s nuclear arsenal was recycled into fuel for nuclear power plants in the U.S. In fact, 20,000 Russian warheads have been dismantled and recycled into fully half of the uranium used for power generation in U.S. reactors. By the year 2000, uranium ore was selling for roughly the same price as it was 50 years before. In summer 2000, Invention and Technology magazine published an article detailing the history of uranium mining and its demise, saying that "uranium mining will not be a profitable venture any time soon." The market was dead and its prospects for a recovery were very dim indeed.
Now, however, the U.S. government is on the verge of granting permits for the first new nuclear power plants in 30 years. The soaring price of petroleum in recent years has again highlighted the folly of U.S. dependence on foreign energy sources. Growing concerns over global warming and greenhouse gas emissions are fueling the demand for forms of energy other than coal and oil. Even hard-core anti-nukes are warming to the idea of nuclear power; Patrick Moore, one of the founders of Greenpeace, said in an op-ed piece in The Washington Post, that nuclear energy is "the only large-scale, cost-effective energy source that can reduce greenhouse emissions while continuing to satisfy a growing demand for power."
And the U.S. isn’t the only country with a re-energized nuclear power industry; Russia has unveiled plans to build 24 new nuclear reactors, and China has scheduled building more than 30 reactors (two 1,000-megawatt plants every year for the next 20 years). India is also going nuclear at a rapid pace. Worldwide, there are 160 power plants proposed or currently under construction.
Today, demand for uranium is outstripping the supply and the price for uranium ore has not just risen, it has absolutely skyrocketed. There’s an ore rush occurring in Moab, Utah again — almost 60 years after the first rush. And recently, a landowner in Virginia is trying to mine the largest deposit of uranium in the U.S.. A supply that is worth an estimated $10 billion and is the estimated energy equivalent of 7.4 billion barrels of oil. In the 80’s, Virginia banned uranium mining but, of course, uranium ore wasn’t extremely lucrative then — and money talks.
Personally, I favor nuclear power despite its dangers and by-products; both of which I believe are far less than all other ready-for-primetime energy sources. But as a history addict, I find it interesting to compare the previous uranium rushes to the current one. The first rush in the 50’s was fueled by fears of national security from a military perspective.
The second rush of the 70’s was generated by national security concerns over the U.S. over-reliance on foreign oil. Today’s rush is plugged into America’s growing concerns over rising petroleum prices, our voracious appetite for energy, our continued over-reliance on energy imports, and recognition of the need for clean yet economical energy sources — in other words, economic national security tempered with a bit of environmentalism.

It’s deja vu all over again. –Yogi Berra
November 28th, 2007 — random, software development, technology
An old geek joke says there are 10 types of people in the world.
Those that understand binary and those that don’t.
The same can be said of this shirt.
November 20th, 2007 — rant, technology
And the saga continues…
Again, I received a phone call from Todd, my local telco field service technician, asking me to check my DSL download speed. Again, it was less than 2 Mbps, far below the promised 6 Mbps download speed — and far below the current speeds I enjoy with my cable-based broadband connection.
This has been going on for 3 weeks now. And the saddest part is that the technical personnel for the company responsible for delivering the service, can’t figure out the problem. I suspect they’re trying to diagnose a kludgey system that was crufted together as a stop-gap, "me too", answer to the cable company’s broadband service.
November 16th, 2007 — rant, technology
I’m still playing games with my telephone company trying to get satisfactory performance from my new DSL Internet connection.
My local telephone company field technician called today and left a message requesting that I check my DSL download speed again, saying that the problem should be fixed now. I did. It isn’t.
The saga continues.
November 13th, 2007 — rant, technology
So my local telco field technician, Todd, came out to my house this morning. He hooked up his equipment to the box outside my house and reported a good strong signal there. He then came inside the house and and plugged his equipment into the jack I’m using for the DSL modem and reported a good strong signal there also. He said I should be receiving 6Mbps download speed. He then hooked up his laptop to the DSL modem and ran a speedtest; he got about 1.2Mbps. Now, he’s feeling really stumped and I’m feeling joyously vindicated.
BTW, the DSL modem does have a built-in, primitive firewall but it was not enabled. Todd was surprised at that and said they should always be enabled as no unprotected PC should be put on the Internet. Again, I am intoxicated with a surge of vindication.
Todd tries another DSL modem with the same results. He says there must be a problem up the line with "the programming" in the switch. He also tells me that I’m the first 6Mbps customer on this switch. He sends the problem back to the guys responsible for the programming and says he will give me a call later when they have resolved the problem. Todd then leaves about 10:45 AM.
About 4:00 PM, I receive a call from Todd. He reports that they have now set up my programming exactly like another customer that is using (and receiving) 6Mbsp download speed. He asks me to try another speed test and call him back. I do so with the same results.
So, here I am exactly 2 weeks into my attempted use of the telco’s high-speed DSL service and they still have not delivered their product. In fact, they can’t figure out why they can’t deliver their product. Even if they find and fix the problem, this fiasco does not bode well for when I experience service problems in the future.
Quality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay for. A product is not quality because it is hard to make and costs a lot of money, as manufacturers typically believe. This is incompetence. Customers pay only for what is of use to them and gives them value. Nothing else constitutes quality. –Peter F. Drucker