*KISS*, and please, do tell
Engineering the engineering process
I’m starting to notice this interesting trend in the software industry of corporations that want to engineer their engineering process. That’s right - engineer their engineering process. Engineering a software or a hardware product isn’t easy, I agree, and I know. Predicting the completion and success of a software engineering project is a hugely difficult task, and I frankly think its useless even trying to do so sometimes. Sometimes projects are undertaken without wholly understanding what completing it really entails, or what its dependencies are. Things like time-to-market, competitive products, customer requirements, current team-member workload are all significant factors in determining a project’s “success”.
What’s this all about?
- First, “KISS” stands for “Keep-It-Simple, Sweetheart” So, if you were expecting some vivid description of a wild night I (most likely) did not have, you may want to stop reading now. Actually, come back tomorrow, or maybe after the weekend. <wink>
- Second, “BTDT” stands for “Been there done that” (I stole that from a t-shirt I have that says “Been There Done That, Purdue University”. Someone asked me the other day what that t-shirt is trying to imply, and I told’em, that you’d have to have been to Purdue to understand what that means. Then I realized that that t-shirt doesn’t really help me express anything to non-Boilermakers. Anyhoo…)
- Third, this post is about my experiences with the software engineering industry and how I’m starting to notice that some corporation heads are getting so paranoid about completing their software projects that they’re engineering the engineering process (if you’re head is starting to go in to a recurisve loop about engineering the engineering process which in turn engineers the engineering process, hit Ctrl+C, and then smack yourself in the back of your head, but do keep reading).
What I’m starting to notice…
Project planning slash management is starting to become this tremendously huge buzz in the industry. There’s several methodologies out there that are now supposed to guide us in establishing project success. Seriously, are project managers getting that lazy or that paranoid or even that useless that they have adopt a methodology that they have to live and die by to complete a project? Isn’t that what project managers get hired for in the first place – to ensure that a methodology, ANY methodology, is working smoothly? Why are processes on top of processes being adopted ensure project success? Granted that these days, there are several variables that are thrown in to the mix that makes a project difficult to finish. But, why risk hampering an engineer’s progress if you don’t know if that process is going to work for you?
A few weeks ago, a project manager asked me (contextually at that point in time), “how can we make sure that this gets done?” The person wanted to make sure that the project wouldn’t fail. I gave that person the how-long-have-you-been-a-project-manager look. I turned red, because there were a zillion things I wanted to say then, but needed to be careful about how I worded it. I wanted to say to the person :
- Make sure you hire the right people (so this question about “how can we make sure this gets done” never comes up).
- If you’ve inherited a team, or if you have just been hired as a PM of a team, then do what it takes to understand your engineers, so you know how they work, and they know how you work. There is no pattern in engineering or with humans, so don’t expect things to be the way they used to be.
- Make sure you’re tackling the right problem.
- PLEASE, FOR <your favorite celebrity>’s SAKE, DO NOT INTRODUCE ANOTHER PROCESS. Don’t create another mail alias. Don’t try to create a half-assed team portal. Don’t have a system so people would have the equivalent of what would be a time card. Don’t use the word ‘resources’ more than once a day. And stop pretending to be clever.
Basically, lets not create a problem, when there isn’t one. Anticipating a huge issue and accounting for it ahead of time, is wholly different from throwing your hands up in the air and saying “whoa! lets introduce this new process that will monitor this other process so that this huge issue gets avoided, but when the huge issue does come around, we’ll introduce another process for it”
Being paranoid is a good thing
There’s healthy paranoia and then there’s just paranoia. Being paranoid is good - really. As an engineer, if you’re not paranoid, get ready for some serious heart ache. But then again, if the problem isn’t yours, or if you don’t have control over how things are going to pan out, please, don’t get paranoid about it. Its like anticipating a break-up with your girlfriend or boyfriend. You know its going to happen, but why get paranoid about it now? Wait till it happens, and then mope over it, right? Ok, bad analogy maybe. But you get the big picture, right?
How do you define project completion?
Its funny how project managers, team leads, software developers and software testers can all define ‘completion’ of a software project in several different ways, in their own different ways. As a developer I can say that to meet deadlines, I have “completed” some projects. I’ve even “over-completed” some projects. My testers have “completed” their testing. The bottom-line was that we did what it took to finish our projects. The project deliverables were hugely dependent on our customer requirements and how soon our customers wanted stuff. Granted that in the industry I came from, and the time that I was in that industry, I worked in a largely *reactive* manner – i.e., we waited and waited till customers screamed their heads off about something they wanted and then we’d wait a little more till they decide to go with the competition, then we’d take it personally, fight the battle, win it, make the customer convert and use our solution instead because we believed it was better for the customer, and then had a little party afterwards to celebrate. What I’ve learned, is that the customer comes first. Its meeting their requirements that makes us do our jobs.
So, how do you keep it simple, stupid, umm, I mean sweetheart?
I must say that I’ve been privileged to work with some of the best… Often times, I had a blanket approval to just do my job – no questions asked, no lies told. I had little or no intervention from my boss. Meetings were kept to a minimum. Any time anyone wanted to find out about what I was up to, I’d redirect them to my boss who take care of everything for me. I had a team lead, who is a brilliant brilliant man. He had a PhD, had been in the software industry a long time, had the expertise and knowledge to lead a team, and knew how to get things done. During the first few months of any project we undertook, my team would typically prototype it, to understand feasibility and to draw some patterns. Once that’d happened, a timeline would be created (mostly in something like a text document), with every task’s due-date exaggerated by about a week or so. This gave us a buffer just in case things didn’t work out, but if they did, we came out looking like heroes. That was it. That was all of it. And the company I used to work for has a market cap of $110B. So, this “process” (or lack thereof) worked man…
And, in conclusion…
While entities out there are trying to ‘do-the-right-thing’ by establishing engineering methodologies and processes like Six Sigma, CMMI, RUP etc., I think they’re seriously overrated. (and while we're at it, you know what else is overrated? Sand. Sand is overrated). Please, just get the job done. You cannot adopt a process and expect things to just work. You have to really create your own process over time. It (your own process) is probably not going to be seamless and glitch-free, but nobody ever gets it right the first time.
I have a tough time trying to explain to people why sometimes industry standards aren’t necessarily the do-all, say-all. Sometimes, you have to go through your trial and error iterations to figure out what works best for you. Also, I’d be super interested in knowing – does the corporation you work for have a software-development-methodology-process-thingie that you’ve adopted?