Friday, September 28, 2007

How to be Successful in Business and Life

Being successfully isn't as hard as you might think, especially in today's mostly courtesy- and competency-free society.

Here are four simple guidelines that will help you be successful both in your personal and professional life. If they sound deceptively simple, it's because they are. Nevertheless, if you follow these guidelines you will immediately set yourself apart and above 98% of the population:

Do what you say you are going to do
This is the only guideline that requires any thought. In order to implement this guideline, you must understand the limits of your own abilities. Before you open your mouth: don't say it if you can't do it. If you do say it, then do it.

Be on time
This is easy. It only involves one thing: when you set an appointment, show up on time (See #1). Don't set an appointment you know you can't make.

Return phone calls
This is easy too. When someone calls you, call them back.

If you aren't going to be on time, call
See rule #1. If you're going to be late or can't make it, call, apologize, and reschedule.

Wednesday, September 19, 2007

Muay Thai Developer

Muay Thai is also called Thai boxing. Much like kickboxing, except the knees and elbows are used as well. It's a very aggressive sport. I've been training for a little over three months in it, so yes, I am the actual Muay Thai Developer.

I was in a meeting yesterday and very bored, so I sketched out this comic. When I got home, I fired up Photoshop drew it.

Tuesday, September 18, 2007

So we're using Agile Development, right?

So the other day I'm sitting there, doing Software Engineering Manager things, when along comes one of the ladder rungs above me.

"Got a sec?"

I immediately raise my shields. Not much good has ever come from one of the higher rungs seeking to speak directly with me, or, heaven forbid, and actual developer. It usually meant the rung has just finished reading some industry article and has a brain stuffed full of 'best practices' and 'industry standards' which they now want to 'leverage'.

I sigh without trying to look like I'm sighing and turn away from the WAR (weekly activity report) I was putting together. "Sure."

"What's our development model?"

Ouch. Even worse than I though. Beyond tech and into processes.... I begin formulating an answer that won't make more work for me or my team.

He continues. "I just got this call from [corporate HQ] and he said all our competitors are using Agile development. He wants to know if we are too."

I shake my head regretfully and with great sorrow. "Our official process is about as far from Agile as you can get. Officially, our documented process is Waterfall, except that we skip the design and verification steps."

He looks disturbed. Obviously not the answer he wanted. "Really?"

I continue, relishing his discomfort while I can, because in the end, I'll have to give him an answer that makes him, and corporate happy; it's the only answer he will accept. Trying to lead him to the truth is, ultimately, pointless. But I can have fun making him step in some dog-doo on the journey.

"See, in Agile, you foster a cooperative relationship with the customer. The developers work directly with them to build functionality as required in quick, modular releases." He nods like he understands what I'm saying.

"But we don't do that. We make the customer submit a requirement. Then our requirements section looks at it and decides if it's valid."

More nods.

"If it is, then they validate it and pass it on to System Engineering."

More nods.

"System Engineering looks it over and then passes it to Project Management. Project Management assigns a Project Manager and then passes it to us."

More nods.

"I grab one of the developers and we call the customer and schedule a review."

I wait for him to ask why the PM doesn't do this, but he doesn't, so I continue.

"At that meeting, we take their initial requirement and begin fashioning a v-1 functional requirements document based on their immediate need."

I wait for him to ask why the requirements section doesn't do this, but he doesn't, so, I continue.

"It takes a few meetings, but we eventually complete the FRD and come up with a tentative delivery schedule."

I wait for him to ask why the PM doesn't do this, but he doesn't, so I continue.

"I pass that schedule back to the PMs."

"And then?"

"Well, then we build it. We schedule milestone reviews for the customer to look at sandbox installs as we complete the various modules. If they need changes, they can let us know right then and we can work that in for the next milestone. Along the way, we keep a test install up and running so the customer can review it."

I wait for him to ask why Systems Engineering doesn't do this, but he doesn't, so I continue.

"If there are changed to the schedule, we coordinate with the customer and pass that back to the PMs. Once we get acceptance, we deploy it to the operational network."

I again wait for him to ask why Systems Engineering doesn't do this, but he doesn't. Instead he asks, "So that's Waterfall?"

"No, I said our official process was Waterfall. What we actually end up using is closest to Iterative."

Fear shines in his eyes. "So what should I tell HQ?"

Well, I've had my fun.... "Tell them we're using the Iterative model, which is just like Agile only better because we satisfy more of the user's requirements with the first release."

He beams and goes away happy. He'll probably get a raise. Isn't software development grand?

Thursday, September 13, 2007

My Newest Web Site: Tizags, a Social Bookmarking site

Social bookmarking is system where users store links to web pages that they find useful or interesting. These links are accessible to the public or a specific network, and other people with similar interests can view the links by category, tags, or even randomly. Popular Social bookmarking sites include reddit, Digg, Newsvine, and Del.icio.us.

I don't much use the others, but I visit reddit a few times a day to see what interesting sites other people are finding out. I like reddit, but there were two main things that bugged me:

1. Their search didn't work worth a crap

2. You couldn't tag your entries; you were forced to select from their very limited list of sub-reddits if you want to try to add any classification to you submission.

So, like most egotistical developers, I decided to build my own social bookmarking site that had the features I wanted, looked the way I wanted, and worked the way I wanted. The result is Tizags.

Tizags is pretty much like any other social bookmarking site, except, of course, that I built it.

Tizags in a nutshell:

  • Registered users can submit links to interesting pages or sites
  • Outbound links are direct, no 'nofollow'
  • Tag based classification
  • A WORKING search (hear that reddit fans?)
  • Positive or negative filter by tags or user
  • Super double secret probation algo that keeps new links on the front page long enough for them to be seen (unlike reddit and digg where down voters can keep your link from ever even showing up!)
  • Report feature for inappropriate links
  • Save Links
  • Add Friends
  • Easily filter out links, link tags, or links by users


I made the site live on Friday, 7 Sep. Go check it out, tell all your friends, your enemies, the world!

Tizags Social Bookmarking

How You Know When You're Dealing with Technically Ignorant People

In the real world, I work as a software engineering manager. As high falutin' as that sounds, I'm really only one rung up from the bottom, the bottom being the software engineers themselves. Above me are four levels of local leadership and then 3 or 4 more off at corporate HQ. My immediate boss is at least technically conversant, in that you can say something technical to him and he probably knows what it means, even if he doesn't fully understand it or would be able to act on it. Once you get past him, however, the technical fluency drops as quickly as the salary goes up.

Being the SEM, I'm in meetings frequently, usually local with the next rung or three, occasionally a few rungs past that, and every now and then with the remote rungs from HQ. I was in one such meeting the other day, and growing bored with the the self-congratulatory way they were slinging around industry buzzwords, I began to keep a list every time some rung spouted some bit of nonsense or another.

So here's the list. When you hear any of the following phrases, you know you're listening to technically incompetent and ignorant people:

  • "Knowledge driven enterprise" - I preference ignorance driven enterprises myself, makes me look smarter
  • The word "leverage" in combination with anything (examples: "leverage our legacy systems", "leverage the data", "leverage our core competencies", "leverage our leverage", etc....)
  • "Real world needs" - as opposed to imaginary world needs?
  • "Share across the enterprise" - the enterprise again? Anyway, give me a good, old-fashioned stovepipe app any day, job security doncha' know. This isn't kindergarten, we don't share
  • "Maximize the workflow/our processes/our data/ etc..." - need I say more
  • "Proof of concept" - this means hiring someone outside the organization and paying them a ton of money to tell you how great your idea is
  • "Enterprise change" - I'm getting tired of the word enterprise, and, anyway, don't we fear change? Besides, I LIKE the enterprise just the way it is
  • "Marry the datasets" - That means taking two stovepipe applications you paid a ton of money for that do pretty much the same thing and spending a ton of money to build something new that does the same thing the two apps you just replaced did. And what if the datasets or the same gender? Then we have to do the development in Massachusetts....
These are just a few of the phrases that make me cringe whenever I hear them. They are also phrases that let me know me and my team will be doing a lot of work with no clear vision on the result. After all, in the oft-repeated words of the higher rungs: "they're only web pages, how long can it take?".