Sunday, August 31, 2008

Another Time Burner

Animated Dilbert comics in rapid succession are awesome.

Interesting Talk on Privacy

Steve Rambam gives an interesting presentation on the state of privacy at The Last Hope hacker conference.

Fascinating, humorous, and sobering. Oh, it's almost 3 hours of youtube broken down into 36 segments.

First part is embedded the rest are linked.



Part 2Part 3Part 4Part 5Part 6Part 7Part 8Part 9
Part 10Part 11Part 12Part 13Part 14Part 15Part 16
Part 17Part 18Part 19Part 20Part 21Part 22Part 23
Part 24Part 25Part 26Part 27Part 28Part 29Part 30
Part 31Part 32Part 33Part 34Part 35Part 36

Friday, August 29, 2008

Parallel > Serial

I'm a sucker for a good Mythbusters demo of a principle. This one does not fail to disappoint.
Adam and Jaimie show how a parallel process can produce faster, and in this case superior, results to a serial process.
Enjoy.

Pro Tip: Perform Environmental Changes Now

In my current gig, like many development shops, we are responsible for maintaining our development environments. And like many development environments, the environments change.

Changes in environments are announced via email with accompanying instructions. That's nothing special.

My typical reaction to these instructions are to either do them right away if it is convenient or necessary, or mark the email for follow up and do them when it is convenient or necessary.

When I completely forget to make these changes and my environment is the only one that fails I always feel like a jerk if I end up wasting time trying to fix a completely preventable problem. I feel especially bad if I ask someone for help and end up wasting their time.

Going forward, I'm going to do both, perform the change immediately if possible and then mark the email in case a less proactive colleague should run into issues later in the day when he updates his build.

Whoops, I didn't think this one through

I work in St. Paul, MN. I pay for my parking. Next week I only work three days, (Wed, Thurs, Fri).

The Republican National Convention is in St. Paul next week.

I was concerned about parking during the convention.

My regular parking lot offered a special deal next week for parking, 4 days for the normal daily rate each day. I spaced the whole not coming in for a couple of days when I saw this offer. Seeing this as a way to secure a spot and not pay extra I jumped at the opportunity.

So, I paid for 4 days and I will only use two of them.

Any protesters or Republicans want a parking space in Downtown St. Paul for Monday or Tuesday next week?

Thursday, August 28, 2008

3 years already?

It's been about three years so I'm going to retire my old home workstation.
I picked out the parts at NewEgg. My wonderful wife will get barraged with a slew of packages in a few days.

Katy, you're awesome.

The reason I ship parts to my wife is because she works in a small office. I work in a large office as a contractor. I'd consider myself very lucky if any of my packages would find themselves to me.

I've made a few decisions on the new workstation:
1) Dual monitors--two 22" monitors.
2) Windows XP Pro SP3. Sorry, don't need Vista yet.
3) Micro ATX case with an Antec EarthWatts power source.
4) External Hard Drives for media storage.

The big thing I'm looking forward to is having a couple of big monitors. I love multiple monitors. This is the first box I've made for myself since I became enlightened to the benefits of multiple monitors.

Staying with XP shouldn't be a big surprise. I just don't feel like I have a compelling reason to use Vista. I felt the same way with 2000 before switching to XP.

The decisions to go with a smaller case and with an 80 Plus power source is to try and reduce the power consumption by the system. My previous system was created with absolutely no consideration to power consumption or noise. This one should run much quiter.

The external hard drive decision is an attempt to further reduce power consumption. I can turn the external off whenever it is not in use.

I hope this new system gives me as much good use as its predecessor.

Wednesday, August 27, 2008

Traffic Accidents: Stop and Look

I can understand Tom Cruise stopping at accidents because "[He] know[s] that [he's] the only one who can help", but why is it that everyone else slows down?

In the Twin Cities it's unbelievably bad how many people slow down to a crawl at the most trivial of accidents to gawk.

Please stop doing that.

Thank you,

Paul

Tuesday, August 26, 2008

More Discussions on Google's Decline

Slashdot, has a post Has Google Lost Its Mojo? Oddly timed after I opined that I thought the culture at Google will change for the less freakin' awesome in the weeks and months to come.

I don't think that anyone expects Google to sustain the level of kick ass perks. Is sponsored child care the next perk on the chopping block? $57,000 to have two kids in day care?!? I'm in the wrong business. I'm sure I could take care of 40 kids by myself. In my fantastic theoretical no taxes or expenses dream world I'd be a millionaire in a year with enough left over to take all the kids to the circus.

But I digress, there does seem to be some smoke coming from the Googleplex. Valleywag wrote a follow up piece detailing the challenges in Google's kitchens.

I have to wonder whether Google has created many monsters with all their perks. A sense of entitlement seems to go hand in hand with Google culture lately. The Googlers have grown accustomed to working in a perk filled palace complete with nameless lackeys. It's like the town of Naperville has given its peoples' collective sense of self importance, sense of entitlement, and manners to Google.

It might be best to take a little bit away from them for a while and let them walk on the ground again.

It will be interesting to see where Google goes from here. I believe that the perks are going to continue to be downgraded and removed as the company fails to sustain the levels of growth that it experienced over the last four years. These are the times when we will find out what kind of company Google is.

It's easy to roll out the clever perks and pay lip service to how much the company values its people when the cash is rolling in. When times get tough and real decisions need to be made, that's when you find out what the company is made of.

My prediction is this: We will hear less and less about what an awesome place Google is to work. Instead we'll hear more about whatever it is that makes money for big G.

Monday, August 25, 2008

The Beginning of the End of Google as we Know It?

Valleywag is reporting that Google is rumored to be considering cutting their culinary employee perks.

EDIT: Now they are reporting that the cuts are directed at facilities that don't house technical staff.

This shift is not a good sign for Google. I don't mean to blow this out of proportion, but I've always viewed perks and their addition/subtraction as a bellwether for corporations and their culture. If perks are being added, like they seemed to be at Google for so long, things are going well. If they start taking them away, well you know the company is starting to hurt.

Duh. A better performing company is going to have more room in the budget to reward their employees. That's nothing new.

Perks are more important to a job than most people realize. Take for example good coffee. If an employer provides coffee that is as good as a Caribou--I don't care for Starbucks--or another coffee shop, far fewer employees will make mid day trips to their local coffee shop. More time in office is more time adding value.

That's all well and good, but something really interesting happens in the relationship between the employee and the employer when perks and benefits get taken away. The employee will feel that they are being compensated less for their work. They used to receive a combination of salary and perks for their work. Now they receive the same salary and less perks.

What is also interesting is the snowball effect that perk reductions can have. Cutting costs in a category give an immediate savings. An expense is eliminated at no immediate perceived cost. Nobody is going to quit over taking dinner away.

How about breakfast?

What if, instead of having trained professional chefs making breakfast the company now only provides a continental breakfast, but gives employees the option to purchase what they used to get for free? Who knows what the next step will be. But I believe there will be a next step, it's far too tempting to pass up. Who knows what it will be.

If only some up and coming managerial type could think of a way to improve productivity by 20%?

Perks do add value to a company. The value is hard to monetize because the perks buy loyalty and efficiency. Loyalty, because people become attached to the perks and experiences that they facilitate. Efficiency because people are able to make use of the perks that to achieve goals that would normally take time away from their work days, e.g., on site day care, on site dry cleaning, on site concierge services and errand runners.

I do believe that the perk reductions will hit a point where the people at Google feel that working there will become very non-Google. It will start slowly, but I expect to hear not about the creative new perks at Google, but instead hear about the ones that get eliminated.

Sunday, August 24, 2008

Can't Beat Free

Classic Cat is a nice catalog of freely available classical music. Songs are listed by composer and performer. I've never heard of any of the performers, but I'm pretty ignorant. The sound quality of the songs I picked up sounded good to me, but I'm one of those guys who can't tell the difference between a $300 home theater in a box and a $10,000 stereo.
http://www.classiccat.net/index.htm

Friday, August 22, 2008

Fun Fact

My short term memory is very poor, yet my long term memory is uncanny.

Thursday, August 21, 2008

The Real Challenge For Agile Development Isn't In Development It's Everyone Else

I think that within the agile community we focus on trying to produce the most value with the least amount of resources and in the shortest amount of time. We don't care about anything else. We look at conventional software development practices as a wasteful and antiquated set of rules that were established when the biggest logjam in software development was waiting in line at the punch card reader.

As software people, delivering value is what is important to us. It is logical. We are continuously refining our processes and practices to find what delivers the most value with the lowest amount of wasted effort possible.

The agile movement in software development is a wonderful effort that is making fantastic strides to improve the process of delivering value through software.

I love smart people. I love to be around them. There's nothing that pleases me more than to feel that I am the dumbest guy in the room. The atmosphere and culture around the agile software movement effervesces me with wonderful positive emotions. I feel that it is a veritable School at Athens--not the Bulldogs.

Did I mention that I believe that unless major changes occur, agile development will fail to uproot waterfall as the methodology of choice for commercial software development? Is it because commercial software developers are stupid? Well, not all of them. Not even most of them. Stupid doesn't come into play.

The reason that I believe that agile software development as it is today will never gain wide scale acceptance in the industry is because the people who make the decisions, the deciders if you will.
Deciders are the people like the people in finance. Don't they really have the ultimate say on whether projects or practices go or don't. They are the ones who say whether the company will pay for something. I'd say that these are the people you want to sell.

What do people in finance have to do with software development. Everything and nothing. Everything because they pay for it. Nothing, because, unless they are participating in developing new financial software, they aren't going to recognize agile methodologies as viable. To them, XP and agility sounds like some crazy ponzi scheme.

XP, great practices, bad name. If you put Extreme Programming's name into context it makes sense. Extreme Programming is called extreme because it is a collection of the best practices in software development concentrated and cranked up to 11. It's an extreme set of excellent practices.

It does not help the cause that XP people tend to be zealots. Why shouldn't they be, it can work very well at delivering value with little waste. If I found something radically different from the norm and wanted to share it with the world, I'd be enthusiastic about it too.

Do you XP people know what it sounds like when you try to tell people in the other parts of the company about XP? You sound like an idiot from the start. eXtreme Programming, woo hoo! Yeow. Let's put a half pipe up in the break room and replace the coffee machine with a Mountain Dew and Red Bull fountain.

To them you look like these guys. Doing crazy stunts, bucking the system. Sticking it to the man. You guys look like a bunch of fly by the seat of your pants irresponsible risk taking idiots to the members of the more conservative areas of the business.

Let's get back to punch cards, sadly, I'm not talking about the promotional cards that I get at my favorite pizza place.

Software development back then was rigid and structured. It had to be. Computers were expensive and time on them was scarce. In those days people planned out their work upfront. They physically had to.

To take a concept and turn it into software, a person would need to turn that concept into a set of commands. Then enter those commands into a machine that would punch holes in a cardboard card. Those punch cards, oh I'd really like a Toto right now, took some time to fill out. Then they would need to be fed into a card reader that turned the instructions on the punch cards into instructions that the big fancy computer could read. In a few hours, you might get a result from the computer that would tell you if your program works or not.

By whether or not it works I mean, it will tell you that your program failed and send you back to figuring out what went wrong. You then would spend several iterations of analysis and fixing until the software finally worked. And then if a change order came in, a big chunk of that process would need to be repeated. That was expensive and the finance people knew it.

No CFO worth his salt would have allowed software to be developed in a way that allowed iterative processes to preside. It would be prohibitively expensive and our grandchildren wouldn't live to see it reach completion. The best way to make sure that development time didn't spiral out of control was to do all of the design and product definition up front. Writing plans out on paper is relatively cheap.

The other benefit of this process was that it was more predictable than not having a structured plan. It was relatively easy to turn the Big Up Front Designs into a task list with milestones. Oh, what could be more predictable? Is the project on schedule? Let me check the task list?

Finance people love predictability. Wall street rewards it. If a public corporation delivers within their quarterly estimates, investors buy more of their stock. If they fail to meet their numbers, even if they outperform them, the perception of the company by investors is that the corporation is volatile and not a good investment. If you deliver on your estimate, you are rewarded. If you fail to deliver on your estimate, even if you outperform it, you are punished.

To our friends in finance, the deciders, predictability is one of the most favored traits to a business unit. If they can count on an area of the business to do exactly as they said they would, the financial people will favor them, i.e., the predictable business unit's funding is approved.

Unpredictable business units are terrible to finance people. They have no idea what kind of return on investment they will get. Maybe it will be a home run. Maybe it will be a total waste of money. It's usually easy enough for the financial people to predict though, deny or cut off the funding and the outcome of the project is pretty well guaranteed.

This brings me back to agile software development. It's great that we're working on ways to deliver more value with less resources in less time. Nobody is going to argue that it is a bad thing. Agility's greatest weakness and its greatest strength is its instability. Agile methodologies are unstable by design in the same way that fighter jets are unstable. Cargo planes are stable, they lumber through the sky, fighter planes are so unstable that many of them cannot fly without fly-by-wire computer controls.

Agile methodologies are modeled against the real world. The real world has change. Lots of change. Change all the time. That's why agile software development makes sense to developers. It's a way for people to produce the most valuable software by adapting to changes. The great strength of controlled instability is, you can turn on a dime. If a priority were to take precedence over the current plan, the agile team will waste far less energy changing directions than the team that has their task list broken out.

The big challenge for IT professionals who want to adopt agile practices is to placate finance's need to perceive projects as being predictable. That is, they want to know that on a certain date, and not well before that date, the project that they are paying for will be finished. Better yet, they'd like to be able to check in on a project from time to time and ask how it's going.

Using agile methodologies, it isn't that difficult to deliver a product on a given date. The challenge is convincing the people with the money that it will happen. Edward Tufte says that "Details give you credibility." Providing lots of details upfront is difficult if the designers are postponing all irreversible decisions until the last responsible moment. I would submit that teams should defer providing details about the implementation itself and instead provide a detailed plan for the project schedule.

If the project is defined as having a minimum set of features to be considered functional or acceptable as quickly as possible, then the other details are just gravy. Hit the minimum features so they are functional and then prioritize them and improve on as many aspects of the project as the schedule will allow.

Instead of culling feature specifications out by name within a document, why not just name them as a feature set. Be very specific on what is the minimum acceptable set of features, but only be specific in what they will achieve. Go no further than specifying the minimum feature descriptions upfront. Beyond the minimum features, give the least amount of description possible. Leave those decisions until when the context of the application and stakeholders' feedback can shape those decisions.

The biggest key to getting other areas of an organization to adopt agile methodologies is to use language and descriptions that don't discredit the practices right away. Instead of letting the zealots describe agility, have people who understand agility, but also understand the people who ultimately decide whether the company is going to pay for agile projects.

That's really the big hurdle is communicating what agility is without making it seem like some sort of trick.

Getting buy in from the rest of an organization is going to be the greatest hurdle. Everything else is trivial in comparison. We can refine our techniques to make developing higher quality software more efficiently but it really doesn't matter unless agility can be sold as a superior option to the rest of an organization.

One of the most damaging things that can happen to a group that wants to be agile is for their company to half support it, one of those ok, we'll let you do iterations and we'll let you guys have stand up meetings, but we're going to require detailed documentation up front... What happens is the organization says it's letting the team be agile, but it isn't. You get a team that has some practices that came from agile methodologies, but the project itself is still very waterfall.

I believe this type of half adoption is very damaging to organizational adoption of agile methodologies. I believe it is, because that project is perceived as being 'agile' when in fact it will be a mix of many practices. It may work, but it probably won't work dramatically better than the old methodology, because in many ways it still is the old methodology.

If the agile project fails, as these types of 'agile' projects failed at a former employer of mine, the blame was really easy to place. People blamed those crazy agile ideas on the project's failure. The blamestorm was that company's retrospective practice. The damage was done though. The people who made decisions there only knew one thing about agile projects, they fail--it's not like the non-agile projects don't fail. If one wanted to get that company to be more receptive to adopting agile methodologies they could do themselves a favor by calling all of their projects the salmon filled waterfall project. Lay the blame on the old methodology and the decision makers will rush to the extreme opposite of waterfall.

The big problem with getting a company to embrace agility is getting them to embrace the whole ideal. Agile development is too often sold in pieces, but usually the pieces that aren't essentially agile, e.g., continuous integration, TDD, stand up meetings. Those things are good practices, but they don't essentially change the methodology.

The essential piece that is so hard for non-believers to adopt is, as Mary Poppendieck says, "deferring all [commitments] until the last responsible moment." For agility to succeed, I believe that an organization's culture must embrace this ideal of deferred commitment. Anything less is not agility and should not be sold as such.



That is the tough pill to swallow in my opinion. To me it has always made sense that decisions made today are often reversed tomorrow. I've never been comfortable making decisions before they need to be made. It's in my own personal wiring to want to defer decisions. In the same way that I am very uncomfortable making a decision today, there are people who are very uncomfortable not making a decision today. People want all of the details to be known upfront.

Getting those people to be comfortable with allowing decisions to be deferred is the only way to get an organization to adopt agility. If the organization's culture is not receptive to deferred commitment, I don't know what will make them comfortable. If I were a developer in a culture that does not accept deferred commitment who wants to work in an agile environment I think it would be easier to go somewhere else or start my own company.

Wednesday, August 20, 2008

TED.com is my new Addiction

What can I say? I'm a sucker for high quality presentations. There are lots of them at http://www.ted.com/. Look at this one on slight of hand card magic.
Definitely worth checking out.

8/19/08 Otug Meeting: Agile 08 Retrospective -- My Retrospective

The Object User Group hosted a retrospective of the Agile 08 conference. A very good group of approximately 25 people attended. Among the attendees were Tom and Mary Poppendieck.

What a pleasant surprise to finally meet them. I had a chance to chat with Mary. I didn't mention that I've been publicly admiring her writing on this blog. NOTE: Mary, you write excellent essays.

Agile 08 sounded like a wonderful conference. The vision for the conference was that of a large multi-stage music festival. Each stage hosted a theme, e.g., the main stage had the more well known speakers, but there were also stages with themes of leadership, coding, quality, etc. There was also live music that was provided by the attendees. It sounds like a wonderful time. Agile 09, is going to be in my home city of Chicago. I may just need to attend. Hopefully I will think of something valuable to say and have the opportunity to present.

One of the themes that surprised me is the movement away from iterations. Instead of having iterations, some teams just have regular releases based around a minimum useful feature set.

The advantage of having a system like this is the release is scheduled around the time to develop the most valuable features. If it takes 3 hours to develop/test/approve a feature that adds sufficient value to the business to warrant a release, why not have a release based on that feature instead of waiting until the next iteration? Iterationless development was said to be well suited to supporting products that are mature or in maintenance mode.

Iterationless agile development was recommended for mature teams that enjoy good relationships with their stakeholders. As Tom Poppendieck said, "Iterations are because people don't trust [each other]." Lacking iterations requires trust among all parties involved.

Another theme that was discussed is the practice of promiscuous pair programming. PPP, or 3P as I just called it, is a practice of pair programming and regularly changing pairs within a day. More experienced programmers would rotate between less experienced programmers. One of the benefits of doing this is gaining the benefit of having new perspectives from the less experienced programmer and knowledge transfer from the more experienced programmer.

The interval that was said to be optimal was between 45 minutes and 90 minutes. The discussion digressed around David Hussman's pomodoro, or tomato timer.

Hussman employs the use of a tomato shaped cooking timer to set work/break intervals. Using regular work/break intervals is a way that he believes allows for people to sustainably work well throughout the day.

I have never personally worked in a strictly paired environment. When I was interviewing at an XP shop, I asked some friends for feedback on the practice and most of them said that pairing for them became a pain point. They said that they would get sick of working so closely with the same person. I think that promiscuous pairing would do a good job to mitigate that risk.

The topic of distributed development was another well covered theme. Mary Poppendieck made a statement that strengthens my view on offshoring. She said that European companies are offshoring because there is a real shortage of qualified workers. They want talent and are looking to add value to their company.

One company, which I don't believe was named structure their organizations to support better integration between their European and Indian sites. One of the things that a company did are to create identical facilities. Another thing was having the Indian team start working at the European facility for weeks and then transfer to the Indian facility. They also have an ambassadorship program. The program gives developers the opportunity to work at the other site for a period(a month?). The results of the program are teams that do not suffer many of the challenges that many of us do.

This is a stark contrast to my own experience working in situations where the company is offshoring on the basis of cost. If the motivation is to reduce cost first and provide value second, it is the beginning of a race to the bottom.

How could we have a discussion about agile development with Mary Poppendieck without discussing Toyota? We didn't. Mary praised Kenji Hiranabe's presentation on new car development at Toyota. Some of the points that she noted about his presentation were some leadership traits and how they are perceived, positively/negatively, by Toyota's culture. One surprising negative trait is charisma.

Another interesting facet of Toyota's culture is that in meetings it is expected that the bad news be discussed first. This is a big contrast to other corporate meeting cultures, e.g., Target Corp, where meetings begin with a round of complimenting each other.

Mary described Toyota's product creation practice as a three part process: product conception, product development, and product production. Each stage must be completed before the next may begin. In each stage of the process a different schedule/finish criteria is used.

For Product Conception: it will not finish until it is complete. Product definition is so important that development will not begin until the definition is finished. I see this as being akin to creating a description of what characteristics the product will have.

For Product Development: it will be complete when it is time. Development is schedule driven, the finished state of the developed product will be finalized when time is up. This is akin to developing an early workable product and enhancing it with as many elements from a prioritized feature set as the schedule will allow.

After the meeting, about twenty of us enjoyed fantastic discussions and free iPhone app demos at the Davanni's pizza.

Monday, August 18, 2008

Are Turn Signals Now Optional?

I could have sworn that drivers are required to use turn signals before making lane changes and turning.
Has something changed?

The Fear Of Offshoring Is Causing...

Domestic students aren't getting into software development because they fear that the jobs are going overseas.

The jobs are going overseas because, among other reasons, there aren't enough available domestic software developers

"That's some catch, that Catch-22,"

Security Alert: Please Don't Give Out Company Secrets to...

While answering a somewhat vague phone call from someone this morning I was reminded of a security measure that was in place at a former employer.

From time to time we would receive email alerts, usually in batches, through the assistant to our VP, from the security team. The alert would state that someone purporting to be from company X was calling trying to get information from the company and that we should refer them straight to security if we should find ourselves talking to them. These things would come in batches, and the only change in the message was the company name, and often not by much.

The thing that always struck me as odd about the alerts is they instructed us to not give away proprietary information to people claiming to be from a specific company. Did that mean that it is ok to give away company secrets to people from other organizations? Also, could someone give good instructions on how to transfer a call?

If I were in charge of security I would do what I could to educate people on how they can be susceptible to social engineering and deception. Listen to this mp3 of the 2600 guys at The Last Hope, to hear how someone can us a phone to make people do things they wouldn't normally do.

I don't think that sending out every time someone tries to pretext the company that informs people to refer the pretexter to security is the worst way to handle threats, but I think it is reactive. The issue that I take with this method is that the people who have the ability to disclose information don't receive any training on how to identify callers of ill intent.

Friday, August 15, 2008

Morning Time Abyss Failblog

Failblog is a nice collection of pictures and videos that show failures. It's an addictive hit of schadenfreude.

Thursday, August 14, 2008

Good Essay on How to Make Meetings Not Suck

Steve Tobak wrote a really nice guide on how to run effective meetings at CNET.

The point that resonated with me is this gem:
Every meeting has a start time and an end time. That means it starts on time and ends on time. If someone is chronically late to meetings, the others must bring peer pressure to bear on that individual. If most of a company's executives exhibit this trait, then find another company. It's a sign of immaturity and disrespect for others.
Being late for meetings somehow has become a norm in a lot of companies that I've worked at. I'd love to see an environment where people were less complicit to tardiness. Better yet, I'd prefer to see a system where people had time between meetings so they could make it to their meetings on time.

Bonus read: Tobak's Do You Have A Dysfunctional Workplace? It's chock full of office anti-patterns.

Favorite Tools: Launchy

The unprivileged among us who do not yet have our own Macintosh computers have long envied the Macintoshed few who are able to fire up an application(via Quicksilver) with just a few keystrokes instead of having to:
  1. put your hand on the mouse
  2. locate the cursor
  3. hit the start button
  4. go to programs
  5. find the folder that the program is in
  6. click on the program
whereas the Macintoshians are able to magically get some little window to appear and then type a few letters and their app shows up. GRRRR!!.! I swear every time I see Nate Schutta give a presentation where he can pull up whatever application and pull off a demo whenever he wants with absolutely no effort whatsoever it makes me furious with rage.

Ok, I'm exaggerating, but Quicksilver's a pretty cool program that was enjoyed by few.

Launchy does the same thing. Launchy works on Windows. Launchy works on Linux. Launchy is open sourced. Launchy is free. What could be cooler?

Load up Launchy and you will be ing your applications open.

Schneier on Security the book

Looks like Bruce Schneier has a new book coming out:Schneier on Security. It is a collection of his essays on security.

I've made no secret that I respect Bruce Schneier's opinions. I was a big fan when Applied Cryptography helped me implement a type of encryption algorithm for a job under a tight deadline.

--Let me extend a professional note that there are many things wrong with regular software developers coding their own encryption algorithms. Also, let me note that there are many things wrong with implementing any type of security in a timeline that would cause its development, and more importantly testing, to be hurried. I would also like to note that I advised against rolling our own encryption for that project upfront and I would recommend that software developer do the same.

Security is a tough field of study. It is a field that combines engineering and hard sciences with human sciences. Bruce Schneier is the first person, in Beyond Fear, who explained the dichotomy of security to me. In security there are the elements of perceived security and actual security.

Schneier argues that each is equally important. I agree.

What makes this challenging is there are very few people who are comfortable operating in both realms of security. What I find very interesting about this field is that one element of security is considered a 'hard' science, and the other a 'soft' science.

There aren't many scientists who are comfortable operating in both realms. Schneier seems to operate within both realms with great aplomb.

I recommend reading Bruce Schneier's books. They contain excellent content and are enjoyable to read.

Wednesday, August 13, 2008

Good Read: Cargo Cult Methodology

CIO.com has an excellent article Cargo Cult Methodology: How Agile Can Go Terribly, Terribly Wrong.
The essence of the article is adopting agile practices in an organization that is unwilling to adapt to the differences in agile methodologies, i.e., an organization that demands that a project forecast and write their requirements upfront isn't agile. Instead they are waterfall projects that take the guise of agile projects.
The success or failure of the project really has no bearing on the viability of agile methodologies, but the perception from the organization is that it does.
It's a good quick read.

Tuesday, August 12, 2008

From Errol Morris: Photography as a Weapon

Photography as a Weapon. This is an amazing essay about photography, deception, and their history together.

Put Your Hand In a Bucket of Water

A friend* of mine told me a story about when he left a job after a substantial tenure. My friend wondered how much he would be missed by his coworkers. A colleague of his told him that he should put his hand in a bucket of water and then remove it. The void that is left behind is how much he will be missed.
I think there's a lot of truth to that analogy. When we leave a place we miss having the people around, and we miss how they did the work, but people fill in the void that is left.

* Because he called me Joseph McCarthy the last time I attributed his full name to a quote I will not mention Dale Mensch by name this time.

Agile Stress Points

2 weeks, 1 full iteration, into my first agile gig and I can see a couple of stress points.

First, let me say that I really enjoy what we're doing. I think we've got a lot of things going well.

As a team, we've managed to complete a lot of features. Actually, as a developer I think this is a very productive way to work. Breaking work down into little pieces and focusing on just those pieces makes developing much more manageable.

I don't think that agile development is magic, or radically different than traditional development. At the end of the day we're still schlepping code. The key difference in agile development is a more awareness on the current status of a piece of a project.

In non-iterative projects I always feel like there's a looming deadline and the success of the project is based on meeting that deadline. The schedule is, if not unrealistic, not very tolerant of setbacks. One key to finishing those projects was to treat the project like it was in crisis from the beginning. Get it done as fast as possible.

Refactoring and rethinking features are a luxury. They kill schedules. A change order to a project is a PM's enemy. I'll venture to say that a majority of features that just seem crazy and out of place are the ones that were spec'ed early, and implemented late.

That's the pain of a traditionally managed project, the push at the end to finish outweighs assessing the viability or the functionality of the work that's being done.

I can see some stress points with using an iterative methodology though. I think it happens at the project manager level. A project manager typically is expected to be able to provide a status for a given project and a forecast for when the project is finished. These are basic expectations that are put on a PM.

Providing a status is easy for the iteration, but the people asking don't usually care about the iteration. One thing that iterations do is expose pain points early. That's the strength of being iterative. You get an opportunity to take care of the pain early and focus on what works. The downside of being agile is the ugly stuff comes out early. Things look as bad as they are, but worse than if the project were not iterative. In those projects the ugly stuff comes out closer to the end. If you're a PM, the project looks worse upfront than at the end. This is a case where, visibility is a strength and a weakness.

The other pain point is providing a forecast. That's tough at the beginning of a project. If you go by the velocity from a tear down chart, it's not going to look very good. Projects start slower than they end. Putting a PM in a position to say that their project is not going to end on time early. To a PM, that's starting off on the wrong foot. Ironically, I think it's setting a baseline worst case scenario. If the estimates are based off the velocity of the project and the velocity increases, then the estimates shouldn't slip out.

From this vantage, it would appear that more buy in is needed outside the project. If iterative projects are allowed to succeed I think that will slowly happen.

Monday, August 11, 2008

Coolest Donkey Kong Out of Lego That I've Seen Today

Very cool.


Play them both at the same time for fun!

Gadget Lab Reports 8 Friends of the Environment

According to Wired.com's Gadget Lab, eight, whoops seven, people purchased "I Am Rich" before Apple killed it.
What Gadget Lab fails to even mention is that these people spent $1,000 on a product that does not harm the environment and does not violate human rights to produce. $1,000 that could have been spent on a new set of rimz or some other obnoxious form of conspicuous consumption.
No, they treat "I Am Rich" as some sort of a scam, while marketing a $20,000 Bentley Laptop is a product that meets a legitimate market need.

Bonus footage: a guided tour to "I Am Rich"

More Frome EcoGeek: Great Software Idea

EcoGeek is reporting Edison, which is a fantastic idea. Edison allows people to schedule when their computer goes into low power use, or shuts it down.
My computer isn't great about going into hibernate at night. XP seems to have a few issues with the hibernation on my system.
I can't confirm it yet, but it looks like Edison may be able to shut the system off at a scheduled time. That would be really cool. I'm sure I could write a scheduled task to do the same thing, but I know that I'll be in my best game ever of Team Fortress 2 when the shutdown script kills my computer.

More environmentally responsible bling

EcoGeek is reporting a nice looking to me--I don't know crap about ugly--the Solarjo power purse. The Power Purse's photovoltaic cells look no more ugly than regular stuff I see people carrying.
It contains an internal battery and USB port to charge electronics. That's pretty cool.
At $285, it's way more than I would spend on a bag, but then again, I've never purchased a purse.
It's still not as friendly as the short lived "I Am Rich", but then again, it's fairly reasonably priced and functional. I guess you just can't have everything.

That's why they call them doctors

A friend of mine, Dr. David, who went through the trouble of earning his doctorate at an accredited university suggested that instead of sending money off to a degree mill that I create my own 'university' and have my 'university' award degrees. See, that's why those guys teach the classes.
Dr. Dave even was helpful enough to suggest Google image searching for a nice looking diploma and then just photoshopping a few words in.
I would like to announce the future Praestrigian University. It will be the Harvard of the Internet as proclaimed by me. I will use Praestrigian University to award myself advanced degrees and titles.
I'm even thinking about awarding myself impressive sounding titles within the University.
Look at that. I now declare me to be the Chancellor, Poet Laureate, and Assistant Janitor of Praestrigian University. Hooray for me.
So now, instead of saying "I didn't send $35 away to some degree mill to be called doctor.", I will say "I didn't go through the trouble of fabricating a fake online university and awarding myself a doctorate in something absurd just to be called mister by the likes of you!"
Very nice. I have found a way to be obnoxious and arrogant.
Have a good week.

Friday, August 8, 2008

Steve Jobs and Apple are Playa Hatin' the Environment!

Steve Jobs, I'm calling you out on this one!
I learned that "I Am Rich" is no longer available at the iTunes store.
How dare you kill "I Am Rich"?
"I Am Rich" is the most environmentally responsible addition to the bling-industrial-complex and you killed it?
What the hell is wrong with you Jobs? Instead of buying "I Am Rich" for a very unreasonable, yet easily reachable, $1000, now morons will buy spinnaz or some other bling that actually requires real resources to create. "I Am Rich" requires nothing. It doesn't do anything bad to the environment.
I was going to buy "I Am Rich", but now I'm going to have to do something else like ask my dentist* to make a new grillz with diamonds that were mined by children, or some other way to let the ladies and the playaz know that I can waste money in creative ways.



*This article is satire. To the best of my knowledge, my dentist does not do grillz.

Theater Review: The Government Inspector: Guthrie Theater 8/7/08

"Fat, drunk, and stupid is no way to go through life son." That may be, but watching fat, drunk, and stupid on the stage is one hell of a way to spend an evening.

Nikolai Golgol's The Government Inspector is a farce about the officials in a corrupt czarist Russia town who mistake the identity of a visitor for a government inspector.
The town's officials are corrupt, incompetent and dumb--not like the current leadership of the US--oh zing!

The town's officials learn that a government inspector is coming to town incognito. They scramble to whitewash their corruption and incompetence. In true Three's Company Fashion--and I mean that in a good way--the town's officials mistake the identity of the inspector for Hlestakov.

Hlestakov's a broke young braggart who travels from town to town on a drinking and gambling and whoring bender staying a half a step ahead of the debts that he accrues at each stop.
When we find Hlestakov, he is broke, dispaired, and exhausted his credit at an inn. A very funny scene unfolds when Hlestakov believes the procession of constables are surrounding the inn are there to encarcerate him while the mayer is trying to find a way to bribe Hlestakov. It all unfolds from there. More can be read about the story here.

The Government Inspector may contend for my favorite show of the 2007 season. It definitely made me laugh the most.

I thought that the costumes and the set brilliantly set a cartoonish tone for the play. The movement, music, and the dialogue contributed to a light, lively, and humorous experience.
To get an idea of the tone, there is a gallery and a video of the production on the Guthrie Theater's web site here.

I think the thing that impressed me the most is how the actors performed--until you see jokes delivered poorly, it is tough to appreciate good comedic delivery. Comedy is often the most challenging form of acting. Comparatively speaking, to make an audience sad is like shooting a fish in a barrel compared to the nebulous and elusive emotion of laughter. It is easy to make an idiot laugh, it is difficult to make a room full of people laugh. The production of The Government Inspector made an entire theater full of people laugh repeatedly.

The Government Inspector plays through August 24, 2008. I highly recommend seeing it.

Thursday, August 7, 2008

From Lifehacker: Top 10 Conversation Hacks

Lifehacker has a great list of conversation hacks. I think the using body language to end a conversation could have come in handy when a certain former colleague would discuss with me how much he likes Jesus and would not stop.

How to detect BS

Great write up on BS and how to detect it at ScottBerkun.com.

What is Dannon Trying to Say About Activia?

I get it that Dannon is selling a product that helps digestion. That's cool.
Digestion is important. I like to digest almost all of my food.
I like yogurt.
Somehow, as a man, I get the feeling that Activia isn't for me though.
Why is it that the commercials only have women? For the purpose of this entry I'm saying Jamie Lee Curtis doesn't count as a dude.
They talk about helping digestion in the same vague way as commercials in years past had pleasant chats between mothers and daughters about that not so fresh feeling.
Is this a woman thing? Is it a menopause thing? I dunno. Could someone explain this to me? Thank you.

EDIT: Looks like it's just a marketing thing according to Slate.
Wikipedia has an entry too.

My question is why market exclusively to women? It sounds like a delicious product, but I can imagine the looks I'd get if I were spotted consuming it. No, actually I can't, I'll need to give that a try and report my findings.

Does Engineering Take a Back Seat to Market Forces?

I was thinking about the effect of stock analysts and capitalization on software development in publicly traded corporations. My former company in particular.

In a nutshell, capital expenditure is why IT professionals are required to report their time against capitalizable projects. I'm not an accountant, I don't really understand much about it.

What I do understand is that companies pay money for their IT labor and it can get categorized in one of two ways, capitalized or not capitalized. Capitalized expenses are considered better because some of that expense can be used to add value to the company as an asset. In traditional companies, it's like a bakery buying a mixer. The expense they spend turns into something that adds value to the company.

For publicly traded corporations this is very attractive. An increase in corporate assets is believed to help increase the corporation's stock price, i.e., maximize the short term value of the corporation.

My own theory is that most of the money that gets invested is through institutional investors that look at companies through their 10Q statements and other demographic information. When analysts look at IT departments, they are typically more interested in seeing that the expenses fit a certain profile, lots of capitalized expenses and lots of offshore labor seem to fit the profile of a well run IT department from a stock analyst's point of view, but I'm getting ahead of myself.

Companies try to manage capitalized and non-capitalized expenses. I think of it like good debt and bad debt. They say good debt is stuff like house payments and education. You're borrowing for things that add value to your net worth.

Bad debt is like credit cards, auto title loans, tax refund anticipation loans, and pay check advancement loans. Actually, in that company the credit card debt doesn't seem so bad. They are bad though because they, in and of themselves, don't add value and the terms for them are unbelievably bad.

My former employer tried to manage the balance between the good capitalized expenses and the bad non-capitalized expenses by educating all of the IT workers and holding them responsible for their time reporting. Any time spent working on non-capitalized expenses, e.g., fixing systems when they broke, was scrutinized and one could be expected to be asked to provide an explanation for time spent working on non-capitalized projects.

The company discouraged fixing broken systems through some organizational changes and implementing a resourcing process.

This particular company is trying to sustain a tremendous sustained period of growth, it's something like fifteen years of continous double digit growth. In my own humble opinion, the business will not be able to sustain the growth much longer, and the people who are in charge are afraid that they will not be in charge much longer if they fail to continue to grow the company.

I believe that every area of that company is under tremendous pressure to minimize non-capitalized expenses and maximize the amount of their fixed budgets into capitalizable projects. It is my opinion that the C level managers are now primarily concerned with how stock analysts evaluate the company. One way to do this is to focus expendatures so they can be capitalized.

IT is an especially ripe fruit for this treatment because IT labor costs are comparatively expensive to other areas of the business. In that company, IT engineers are third only to health care professionals with doctorates and higher management.

To the higher ups in a company capitalizing as much of their budget as possible is their number one goal, second is minimizing their non-capitalizable expenses, third--well what is it that IT does? That, in a nutshell is what is wrong with IT departments in corporations.

When the role of the department comes third on the priority list, it becomes clear that aspects of doing your job aren't important.

What suffers? Service and Quality.

Service is what an IT organization should be about. IT is supposed to help the rest of the business do whatever it does. The computers that people use and the software that runs on it doesn't hold any value unless other people in the business are able to use it to do their thing.

Quality is how good the service is. Quality is reliable. Quality is efficient. Quality does not frustrate people. Quality facilitates service.

Sacrificing either of service or quality for the sake of reducing costs is a loser's game. The term that the IT industry uses for this is technical debt. Jared Richardson takes technical debt a step further and calls it Credit Card Software Development. I think Jared has it right.

Technical debt accumulates through making unsound technical decisions. For example, a company that decides to postpone upgrading their computers is taking on technical debt. A company that allows its software engineers to practice undisciplined software development is accumulating technical debt.

The decisions they make today will cost them in opportunity costs down the road. In the case of the computers, maybe it's fine that they keep using the same hardware. In the case of the software, well that's where the debt can really snowball.

To continue the credit card analogy, IT pays its monthly statements through service and quality. Think of the services as the check and the quality is the likelihood that the check will not bounce. If the service and quality isn't provided, the credibility of the department, FICO score, suffers.
Once a department accumulates too much debt the figuratvie double-cycle-billing interest, fees, and universal defaults all begin to take a growing portion of the department's budget and become a very real problem.

In the real world I'm talking about systems failing. Not just outages, but other nasties like data corruption, lost information, and worse. It's the stuff that disasters are made of.

So how does this concept of trying to fit a stock analyst's profile of a successful company's IT department contribute to technical debt? I believe it does in a number of ways, but most importantly it causes external market forces to play an active and prominent role in technical decisions to the point where bad engineering decisions are being made because a stock analyst's opinion takes precidence over engineering principals.

What's the solution to the problem? I think it's two part. One, I believe that many stock analysts have no idea what makes a good IT department. I think they look at companies that perform well and see how they allocate their IT budgets and duck type that as good. Secondly, corporate decision makers need to stop cowtowing to the stock price when it comes to making sound technical decisions. You're the expert on what is right, don't let a profile determine how you do your job.

Wednesday, August 6, 2008

Oreilly OSCON, Lots of Excellent Free Presentations

Holy crap there is a ton of great content at Oreilly's OSCON proceedings.

There are too many interesting topics to name just one, but what the hell here's one that seemed appropriate, The Effects of Stress on Programmers' and Groups' Performance.
Topics include lots of Ubuntu, software technologies, technology issues, and project management.

EDIT: I checked out the slides--very interesting premise. In a nutshell: Compares stress to cocaine and hypothesizes that stress can be just as addictive. Makes other comparisons to stress and other health disorders. Well put together.

Software as Bling

The Register reports that a new application "I Am Rich" is available for purchase for the iPhone. Americans may purchase it for a very reasonable $999.99 while Brits can look forward to paying a jolly good price of £599.99.
I think this is a relatively environmentally conscious way to let the world know how much available credit you are willing to spend to let people know that at least at one time you had at least that much available credit.
What does "I Am Rich" do you may ask? It's bling, its function is to signal to others that the owner has money. "I Am Rich" exceeds this requirement by displaying an image of a really big red gem on an iPhone in a very environmentally responsible way.
I hope that "I Am Rich" ushers in a new era of green bling.

Tuesday, August 5, 2008

I'm feeling those stairs now

It's amazing what 20 flights of stairs will do to your legs.
Good thing the badge works in the elevators now.

2 ways to discredit yourself as a software developer

A friend shared a couple of sure-fire ways to deep six your career at some companies.
  1. Openly, frequently, and clearly state that you believe that UFOs frequently visit the earth and that aliens live among us.
  2. Global outsourcing really does not work all that well.
Point number 1: I'm cool with that. With the exception of my former roommate Michael I can't say that there are many people who have taken that position that I respect.
Point number 2: Sad, but true. It's a touchy topic. Global outsourcing is the new key to success. Wall Street is rewarding companies that have a certain percentage of their workforce overseas.
What do a bunch of investors know about running a company? Hard to say, seems that their prevailing wisdom changes from week to week. My friend Dale once said that stock prices are just a bunch of MBAs second guessing each other. To an extent, I agree. Perception drives the reality of a stock price, and investors contribute towards shaping popular perception of companies.
Regardless of the wisdom of outsourcing to improve the valuation of a company, it is clear that all companies are at least considering leveraging offshore resources to augment their workforce. I'm going to focus on IT, but there are lots of areas where this happens.
IT is the unlucky schlep in the company that gets hit the worst with offshore resources. It's such a tasty ripe budget that looks so delicious to cut. I can see those CIOs thinking to themselves: think how smart I'll look when I replace a bunch of $200,000 a year software engineering contractors with offshore contractors who will work for less than $50,000. I can hire them at 4 to 1 without growing the budget. I can't lose.
I think the temptation to shrink the budget and the apparant, albeit shrinking, disparity between the cost of living between the US and other parts of the world make global outsourcing too tempting an intiative for companies not to try. When the boss says that outsourcing is the way to go, nothing is going to deter him from that decision. If you appear contrarian, the people who decide how pleasant your future will be at the company, may see you as not a team player and decide to crank the fun level for you down a few notches. Why are they so touchy? Well, I think many of them have goals of replacing most of the domestic resources with cheaper offshore resources.
Consider the manager's situation. How do you tell the people under you that you want to send their jobs to a cheaper bidder in another country? This is tough, the workforce has emotional attachments and may, rightfully, feel that their job security is being threatened. The managers will try to soften the impact with misdirection and half truths. They will assure the work force that they are valued and the company expects to need them for years to come.
If they are intent on replacing the stateside workers, it is very important that the stateside workers stay as long as possible. The goal would be best achieved if the stateside workers would participate in training their replacement, um new global partners, until the company is ready to reassign/terminate the stateside employee.
Getting your employees to willfully and knowingly participate while not quit/sabotage your effort to get rid of them is, a very difficult maneuver. I have yet to see this executed well. Every time I've seen it happen there has either been blatant misinformation or a lack of information, neither tactic did much for the relationship between the managers and those whom they manage.
The question that people neglect to ask when they see this wonderful juicy plum of a fruit is whether global outsourcing can work. I think it can, but here's the thing, it won't work the way that companies want it to work. I'm not going to go into details of why, but for the sake of this essay, let's establish the premise that IT development jobs are not easily transferrable from one region of the world to another without realizing significan losses in efficiency by the person filling the position, or those who work with that person. For example, a software developer who can meet face to face with her customer, tester, teammates, and project manager is very likely to be more efficient at delivering the solutions that the customer wants, on the schedule that the PM establishes, with fewer defects. Being in physical proximity with the stake holders of a project increases empathy for the other parties.
The big equation that the people trying to make outsourcing work is how to reduce the inefficiency that distributing a workforce around the globe such that the reduced value or prolonged time in delivering the value is significanltly small enough to justify the cost savings. Is the lesser product worth the reduction in cost?
We make these kinds of decisions all the time in our lives, I was tired of shelling out close to $200 a month for my Comcast triple play, I switched to DirecTv for my television service and saved close to $20 a month for similar programming. The trade off is I have dish on a pole in my back yard, the picture goes out during heavy storms, there are more wires going through the house, and I don't get the same on demand features that I had with Comcast. Considering the amount of television we watch, the trade off was worth it. To put the trade off in perspective with outsourcing, I'd say that going from a local development team that knows the business to an offshore team, you're looking at going from a FIOS home theater to rabbit ears on one of those TVs that you need to hit on its side every once in a while to adjust the picture.
My suggestion to people considering implementing an outsourcing strategy is to look for jobs that don't need to exist onsite. Any job where the workers look bored all the time, is a great candidate. The people who are bored may be the least costly employees, but the cost to provide them benefits is a much higher portion of their total compensation. People who are bored at work are people whose jobs are not demanding, those are the easiest jobs to ship to somewhere else. The people who answer phones, they're usually bored, why pay someone $10 an hour to do it, when you can pay someone $20 a week to do the same thing?
Finally, before sending all work overseas, it is important that people question what the motivation to do this is. Is it purely for reducing cost? Consider the effect on the value and the trade off that making decisions purely on cost have. Competing on cost is never a good long term strategy, it's a race to the bottom.
It's value that people want, the cost is what they are willing to pay for it.

Monday, August 4, 2008

Triumph + Comic Con = Almost Too Easy

Robert Smigel donned his rottweiler puppet Triumph The Insult Comic Dog and visited the 2008 San Diego Comic Con. He proceeded to ridicule and insult the attendees. He kids because he loves.

I love triumph because he kids.

I didn't send $35 off to a degree mill to be called Mister!

I'd like to buy a really cheap PhD so I could correct people with the line.
I didn't send $(insert trivial cash amount) off to (insert unaccredited degree mill) to be called Mister Wiedel!
I was wondering what those of you reader who earned your PhD's think of this bit of smartassery?

Flying Vending Machines

Consumerist has a post calling US Airways Planes a "Flying Vending Machine". This reminds me of a recent experience I had with Northwest.
The wife and I were flying back from California last week. On northwest they no longer give out complimentary "fun size" bags of pretzels nor do they provide any type of complimentary food. I'm cool with that. What they do offer is a variety of food options for a price. One of the options, the one we chose was a $3 bag of trail mix. Delicious. It was very good. Exactly what we needed.
Why would I write about this? Well I only had a $20 and the flight attendant didn't have change. So she took the $20 and said she'd come back. She went up the aisle and back and did another trip to pick up cups. Then she did a coffee trip. When she asked me if I'd care for coffee I said yes. I asked her if she had a chance to get change she said that she hadn't.
She came back to me and explained that she didn't have change. Was I going to have to pay $20 for a bag of trail mix? I asked what we could do to take care of this?
She asked if I wanted anything else from their snack menu and I was thinking, NO.
There was a happy ending though.
A very nice man from across the aisle was kind enough to make change for a $20 and I was able to get my $17 in change. If he hadn't been so kind I would have been out some money. What's wrong with this?
If airlines are going to start acting like merchants by charging their passengers money for things, shouldn't they take the same responsibility that other merchants take and provide a way to make change. I sincerely believe that I may have been out an extra $17 had other passengers not come to my aid. I know the airlines are struggling, but that's no excuse for trying to pull nickle and dime short changes on their customers.

I'm going to have to get used to this

I just received word that I now have security clearance to use the elevators before 7:00 AM. What's interesting about this is I made the request for access just this morning. Within a few hours someone acknowledged and serviced a request.
My expectations have been set by working in a culture where any access request can be expected to sit for a minimum of a week, often to be denied by an unnamed person with no explanation. I don't know how a culture can evolve in a supposedly successful company where that type of behavior is considered acceptable.
Kudos to my client for not being dysfunctional. Am I going to think my client is awesome for every dysfunction that they lack that my old employer had?

Death of a dream team

A former colleague of mine reminded me of what a good team we had just over a year ago. It's really sad, it was probably the best team of people I ever worked with. This is with the one screw off developer that we had. Everyone else was solid. We had a great manager, an awesome PM, our developers were great, and our QA guy was really good. Our primary business user was a horrible person at times, but the rest of them were pretty decent.
It's sad, but it's just another leg to the old 'the only constant is change' argument. If the experience teaches me anything it is that you need to make the most of what you have now and not take it for granted.

Interesting news over the weekend

Quitting my job did wonders for my golf game. For the first time ever I hit the fairway on my first shot. Awesome! I hit quite a few double bogeys, a bogey and a hand full of +3 shots to finish 9.
It was probably the most relaxed I've ever been on a golf course.
In completely unrelated news, so don't infer that anyone in my foursome said anything, a little bird told me that the center of excellence is being seriously rethought. A reorganization may occur within the year, but people who are thinking about waiting it out, might just want to wait it out. Another little bird whispered that my former VP is not impressing a lot of people and that he may be on his way out within the year. Those were just someone's opinion, time will tell whether it turns out to be true.

Memo to file: don't try to outthink client's security system

There's a bit of a problem with my badge. It won't authorize me to hit a floor on the elevator before 7 am. I learned that today. I'm on the 20th floor. I was able to ride up to the 19th floor and thought, this is an easy problem to solve, just take the stairs up to the 20th. It seems that the building's security system thought of this. I figured it out just as the stairwell door closed behind me. I got to go 20 flights down to first floor where door is unlocked.
I found the experience of going down 20 stories strangely reminiscent of an experience I had about 10 years ago. I was fresh out of college and looking for work. My dad was kind enough to allow me to work at his office at the time answering phones. I didn't have my CS degree at this time, only my English degree--PROTIP: English degrees are good, but not by themselves double major an English with something that will get you hired.
The good thing about that job was I could use it to look for other jobs. It wasn't easy going. I had no idea what I wanted to do and when I found positions that looked interesting, Administrative Assistant if I succeed do I become an all powerful Administrator?, and I applied for them. There was probably a good month of my getting nowhere in my job searches. I finally found some companies that would talk to me. They were staffing companies.
One such staffing company had its office in downtown Chicago. I think it was on the 25th floor. I remember this because when I got out of the interview I deduced that the single elevator that serviced this building would take a very long time to get to my floor. So I did what I normally would do, I took the stairs, 25 flights down is nothing.
The only interesting thing about the trip down is that between the second and ground floor was a door with a lock. I noticed this as the door closed behind me. I also noticed that there was no obvious exit at the bottom of the stairwell. There were a few doors, but they didn't have any handles on my side.
I didn't panic. I didn't think about how long it might be before I was discovered in the basement of this building, 3 days? I looked at one of the doors. It was a double door with light on the other side of it. The gap was wide enough that I was able to stick one of my keys through the gap and pry the door open.
The door revealed a restaurant kitchen. Freedom! I walked through the kitchen to the dining area, found a seat at their bar, and had a drink.

Saturday, August 2, 2008

Reward with punishment

Ever have something that was supposed to be a good thing turn out to be a bad thing?
If you're on of those managers who thinks that buying pizza for your underlings is a reward take note, it usually is.
However, it's an awkward form of punishment if you buy the pizza from one of the following places: Pizza Hut, Dominos, Papa John's.
Those pizzas are worse than whatever the people you are trying to reward would have eaten had you not bought crappy pizza for them and had them eat it. If people know that it will be one of those types of pizza, they will find an excuse not to participate in your little pizza party.
If all pizza is the same to you, ask someone who knows pizza what to buy. It won't be as cheap as Pizza Hut, but the people you're trying to reward will genuinely appreciate it.