Uncertainty, complexity, and hard non-deterministic problems

I came across validation on the thought that people management is a hard problem.

From Bruce Eckel’s blog, “Deterministic Software Development“. Bruce talks about management thinking, about why Software development cannot be included in deterministic set of problems and finally about why the people factor in software development is key. He suggests that looking at it in a deterministic sense is a dead-end approach.

Related posts on my blog:Engineering Management” – Sukshma.

You might also be interested in “What is problem solving?” – Michael E. Martinez, on the application of heuristics, goal management, and learning to solve complex problems.

David Seah: Stay focused

For those who are working on their own, there is no one standing behind you to motivate you, to push you forward in your career. I recommend finding mentors, but they cannot be around you all the time. David Seah has found an excellent method of staying focused even when your working alone and has documented it. This is a good read for those who want to be able to motivate themselves. I used a similar method to get through my thesis in graduate school, so I know it can work.

I love the freedom of being a freelancer, but sometimes I wish someone with vision and drive whispered encouragement in my ear: “Good work, Dave! This Flash project you’re working on is a key part of our interactive marketing strategy! All the pieces are falling into place!” But since I work alone, it’s my job to keep myself motivated and away from the dozens of daily distractions that suck productivity out of the day:


Automation is not helping ship reliable Software quicker

Microsoft announced that their long overdue Vista will be delayed even further.

This annoyed a number of Microsoft employees, some who don’t work with Windows, some who don’t even work with Microsoft anymore (ex). But seriously, the effects are far-reaching. I am sure there was considerable thought put inot the decision.
Anyhow, one voice piped in that automation of tasks, including Quality Assurance wasn’t helping: (from Mini-MSFT)

In the last 18 months this org:

1) Cut the number of testers (several times) from approx 50 to now much less than a dozen. Of
course, many top performers also left MS entirely because of middle mgmt in this org.

2) Hired more PMs
3) Cut the scope of testing (anyone done any real code coverage testing lately?)

4) Cut the number of promotions in the test orgs – nothing like a little ‘de-incentivization’ to increase ‘bad attrition’

5) Dictate that everything can and should be automated.
(Ignore that eyeballs catch more in less time…) way to go Darren. Of
course, you
were probably lied to by your underlings, so it’s not entirely your
fault. Uhh, yes it is – you made the call.

6) Hire only a small handful of devs to write automation
code. Oh, and don’t forget to swamp them with added process and have
embittered leads review their code…

7) Hire more PMs

8) Outsource all testing to non-accountable and barely trained CSG firms
overseas (Ever try to translate/clarify a bug written not by a tester, but by their lead based on notes? )

Limit the number of heads
the abovementioned overseas firms can use. > Fewer testers, less
experienced, with little training, a much (ahem) ‘slower’ approach to
testing. Results: Client appcompat % hovering at <40% (GASP –
INTERNAL INFO… better moderate this one out!!!!)

an anomaly for PM’s to ‘splain away. If automation is such a great
tool, why is it not finding more bugs than a small handful of testers
in a lab on the other side of the planet?

Very Interesting observation. The largest software projects are
traditionally proving grounds for automation techniques. I wish the
authors of Windows Vista come out with a sequel to The Mythical Man-Month.

Updated: San Jose’s Mercury News also cites the same book and the Vista delay but in an altogether different context.

The challenge of big software projects was probably best
described by Frederick P. Brooks Jr. in his classic 1975 book, “The
Mythical Man-Month.” Brooks, a professor of computer science at the
University of North Carolina at Chapel Hill, stated then what he called
Brooks’ Law: “Adding manpower to a late software project makes it
later.” The need for latecomers to get up to speed and communicate
with their
predecessors, Brooks says, takes up more of the team’s time than what the added workers contribute.It’s even theoretically possible to reach a kind of software
gridlock, where the team is so big that all its time goes to
communicating among
each other and making revisions — with the project never reaching

Scott Maxwell, you just read my mind!

Attracting, Retaining and Motivating. What’s in it for them? [Now what?] Scott Maxwell

An excerpt:

Stretch them (without breaking them). Think of stretching a rubber band as far as you can without breaking it. This is the fastest way for top caliber people to develop…getting their goals met becomes difficult for them, which they like!

Give them hard-hitting, constructive feedback. Everyone loves feedback, especially constructive feedback, and most managers shy away from giving it. Instead of hoping they will do the right thing and ignoring when they get off track, tell them what you observe and how you what you think (note: you can do this without being a micromanager by focusing on the themes rather than the details). High caliber people can and do want to do the right thing, so it is up to you to help define what that means (btw, you might be wrong, so giving them the feedback and being open to theirs is even better. It can get you aligned with you taking on their view of right quite often. It also clears the air really nicely).

Read the article

IT Careers: Evaluating your job

I came across an interesting article on evaluating your current job. I respect the article for the fact that it is based on the experiences of the author. It isn’t just any joe blo writing about what he thinks the industry should be like. However, I think the tone of the article is tremendously harsh.

The article can be found here [fr.sys-con.com].

From i-Technology Viewpoint: When to Leave Your First IT Job:
“The first layoff is tough. After bending over backward, after being a loyal employee, this is the reward? To summarize how I felt: Disillusioned. Only one thing kept me going — pure ego. You know when the schoolyard bully says something about your mom in front of everyone? But, ignoring the size difference and the fact that he’s already shaving daily at age 14, you step forward and say “Oh yeah?”, with a Brock Sampson-like eye twitch the only warning of the impending ownage? That’s the kind of ego that kept me determined to give software engineering a second shot.”

I do agree with the following points highlighted in the article.

  1. Don’t ever work in cubicles.
  2. An over-bearing management or they think that they know too much.
  3. Management that relies on, but disregards your technical advice
  4. Management that bullies you over your schedules
  5. Jobs that stunt your personal growth
  6. Job commitments that you are not happy doing
  7. Jobs that don’t give you the opportunity for career advancement
  8. Jobs that don’t consider overtime alongwith compensation

I don’t agree that any one of them alone, is reasons enough for quitting your job. Perhaps that wasn’t the author’s point. It is obvious that very few employers will score 10 out of 10 by the standards set down in the article. It is also hard to evaluate each of these requirements against any existing job. For example, schedules can often be tight when trying to meet market demands and when taking advantage of available opportunities. However, it may not be necessary to have to deliver all that is promised on time. A reduced set of commitments can be negotiated upon within the available time constraints. If the management were to then turn down the request to restrict the scope to fit the time – the writing is on the wall. Several start-ups offer stock-options that are worth very little in exchange for loyalty and dedication. It is only a promised compensation, one that may not materialize ever. Is it still a good job subject to the possibility that the employee is willing to risk it?

What is important is to be aware that your ideals have been compromised. Is your job just another job, or is it something that you enjoy doing with a great deal of passion. Do you honestly believe that you had to make that compromise because of your current working conditions? When did it stop being a true challenge and a learning experience? Then again, should having to work in a cubicle be enough grounds for disullisionment? Or is it that I am incorrectly adopting a more conciliatory stance than is necessary?

It is hard to evaluate your employer objectively, what with the growing liability of having to provide ‘diplomatic’ feedback to their employees, feedback that will not have the potential to hurt the company. Be careful when you do so. I wouldn’t be surprised if some companies truly are skimping on the quality of work environment they provide.

Some quotes from the article:
At my last job, I constantly felt dejected. “You’re not growing fast enough! You’re barely in the middle of the pack.” was the kind of feedback I was getting from my supervisor. Much later, I realized they were setting employees up for failure, and then blaming the employee, instead of blaming themselves.

Work is not all bad. A lot of employers say they want their employees to think work is fun. Few employers put their money where their mouth is, and difference is something you not only see – you feel it when you start working for those employers.

Business Etiquette for PhD’s

I came across a short article on Business etiquette.

For Ph.D.’s looking for jobs outside of academe, the insularity of the ivory tower is often a handicap, but it doesn’t have to be. If you arm yourself with a solid knowledge of business etiquette and a sense of how academics are perceived by the outside world, you will have a better experience on the nonacademic market.

Speak Up, Shake Hands, and Smile; Chronicle Careers

Suggested books on business etiquette

In brief,

  • Business etiquette is necessary when dealing in the business world
  • Overdressed is fine, but dress appropriately
  • Rehearse a good handshake
  • Make frequent, sustained eye-contact, it is a sign of confidence
  • Work on nervousness/anxiety signs offline
  • Emphasize on precise written and spoken communication in different contexts
  • Practise the “elevator speech”
  • Practise your “airplane test”
  • Practise your small-talk skills
  • Be savvy when you write your e-mails, timing is important, so is content, and privacy
  • Don’t attempt communication when your upset, high on pot, or just plain out of sorts