Karmona's Pragmatic Blog

Don't get overconfident… Tiny minds also think alike

Karmona's Pragmatic Blog

The Pointy-Haired Boss Alter Ego

September 28th, 2010 by Moti Karmona | מוטי קרמונה · 1 Comment

Robert (Bob) Sutton wrote insightful post about “Good Bosses” which I feel it worth more than just a tweet

With an evidence-based (experience studying and consulting to managers in many settings) approach he have identified a list of key beliefs that are held by the best bosses — and rejected, or more often simply never even thought about, by the worst bosses.

Here are the half dozen I liked most, you can read the rest (+ dedicated post on each one) on his HBR blog post.

  • I have a flawed and incomplete understanding of what it feels like to work for me.
  • My job is to serve as a human shield, to protect my people from external intrusions, distractions, and idiocy of every stripe — and to avoid imposing my own idiocy on them as well.
  • I aim to fight as if I am right, and listen as if I am wrong — and to teach my people to do the same thing.
  • Innovation is crucial to every team and organization. So my job is to encourage my people to generate and test all kinds of new ideas. But it is also my job to help them kill off all the bad ideas we generate, and most of the good ideas, too.
  • How I do things is as important as what I do.
  • Because I wield power over others, I am at great risk of acting like an insensitive jerk — and not realizing it.

@Bob, very insightful – Thanks!

By the way, just added his new book “Good Boss Bad Boss” to my Delver Wish-List… please feel more than free to surprise me ;)

*** *** *** *** *** *** *** *** *** *** *** ***

Random Quote“my comprehension can only be an infinitesimal fraction of all I want to understand” | Ada Lovelace (a.k.a. the *first* programmer)

→ 1 CommentTags: Leadership · Management · People

Run “Hello World!!!1” Servlet on EC2 using AWS Toolkit for Eclipse

September 15th, 2010 by Moti Karmona | מוטי קרמונה · 12 Comments

It started like yetanother-weekend-experiment but once you start a weekend experiment you never know when or how it will end… ;)

I was very curios to take AWS for a quick test drive so I lost six hours of a precious beauty sleep and compiled this blog-post-capsule for future generations.

 

 

The Quest

* Run an “Hello World!!!1” Servlet on EC2 (less than $0.01 per hour)
Create a local development environment using EclipseAWS Toolkit for Eclipse (seems like a really interesting toolchain)

Preliminary Steps

Issues with AWS Toolkit defaults

The plan was to use this tutorial but surprisingly enough this did not work out-of-the-box (apparently due to Tomcat/JDK versions on the default AMI the plug-in is using but I didn’t waste time in making sure this is the issue) so I moved to plan B

 

Plan B – Create a custom EC2 AMI with Tomcat 6.something and JDK 1.6

* Launch an EC2 instance using Amazon’s ami-84db39ed AMI.  (basic Fedora 8 image)
* Use Putty connect to your instance

 

* Install Java on EC2 Instance

Download JDK (“Linux RPM in self-extracting JDK file”)

mkdir /usr/local/java
cd /usr/local/java
curl http://download.java.net/jdk6/6u23/promoted/b01/binaries/jdk-6u23-ea-bin-b01-linux-i586-30_aug_2010-rpm.bin > jdk1.6.0.23-rpm.bin
* Install the JDK
chmod 755 jdk1.6.0.23-rpm.bin # Change the permission of the file
./jdk1.6.0.23-rpm.bin #Install
updatedb; locate javac | grep bin  # this step merely serves to verify the installation
/usr/sbin/alternatives –install /usr/bin/java java /usr/java/jdk1.6.0_23/bin/java 100
/usr/sbin/alternatives –install /usr/bin/jar jar /usr/java/jdk1.6.0_23/bin/jar 100
/usr/sbin/alternatives –install /usr/bin/javac javac /usr/java/jdk1.6.0_23/bin/javac 100
/usr/sbin/alternatives –config java # Change the default JVM from gcj to Sun’s version (if needed)

* Install Tomcat on EC2 Instance

* Download Tomcat 6.0
mkdir /usr/tomcat
cd /usr/tomcat
curl http://apache.spd.co.il//tomcat/tomcat-6/v6.0.29/bin/apache-tomcat-6.0.29.tar.gz > apache-tomcat-6.0.29.tar.gz
tar zxvf apache-tomcat-6.0.29.tar.gz
* Start Tomcat and to verify the installation, load the root page from a web browser: http://your_instance_name:8080
cd apache-tomcat-6.0.29
bin/startup.sh  # Start Tomcat
* Configure Tomcat to launch automatically – Create a file “/etc/rc.d/init.d/tomcat” with the following content:
#!/bin/sh
# Tomcat init script for Linux.
#
# chkconfig: 2345 96 14
# description: The Apache Tomcat servlet/JSP container.
JAVA_HOME=/usr/java/jdk1.6.0_23
CATALINA_HOME=/usr/tomcat/apache-tomcat-6.0.29
export JAVA_HOME CATALINA_HOME
exec $CATALINA_HOME/bin/catalina.sh $*
* Set the proper permissions for your init script and enable Tomcat for auto-launch:
chmod 755 /etc/rc.d/init.d/tomcat
chkconfig –level 2345 tomcat on
* Tomcat should now be automatically launched whenever your server restarts.

 

Are we there yet?

It could be but apparently the plug-in was poorly designed to use none-configurable command lines so I needed to add the following “tricks”:
* Set JAVA_HOME / PATH for your user – Login to your account and change your .bash_profile file
vi ~/.bash_profile
export JAVA_HOME=/usr/java/jdk1.6.0_23
export CATALINA_HOME=/usr/tomcat/apache-tomcat-6.0.29
* Create aliases to your Tomcat and JDK installation (these location are hard-coded in the plug-in)
ln -s /usr/java/jdk1.6.0_23/ /env/jdk
ln -s /usr/tomcat/apache-tomcat-6.0.29/ /env/tomcat
The EC2 instance is ready :)

 

What next?

* Create EBS Image AMI from your instance (it does takes couple of minutes to complete)
* Open your eclipse and start a new AWS project as described in the original link
* Define a new EC2 Server in Eclipse using your new AMI (reminder: the default didn’t work)
* Create your “Hello World!!!1” Servlet
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.getWriter().println(“Hello World!!!1”);
}
* Click Run… this will automatically deploy your Servlet and run it on the remote EC2 instance… Wow :)

 

That’s it – I hope this will help, it does take approx. 1 hour so if you know some other way to make it work, please don’t be shy and comment.

Additional references I used to make it this far:

* Amazon EC2 – Getting Started Guide

 

Free VI Tip for Dummies

80% of knowing VI is just: ESC ESC ESC, i, Type-Your-Stuff, ESC ESC ESC, :wq!

 

 

→ 12 CommentsTags: Cloud · Development · Simplicity · Tools

Underestimation is Underestimated

April 19th, 2010 by Moti Karmona | מוטי קרמונה · 8 Comments

Underestimation is Underestimated (a.k.a. Overestimation is Overestimated)

Sometimes it seems like we have an underestimation gene embedded really deep in our cognition but for some “obvious” reason (e.g. underestimation! :) most manager will rather “fight” overestimation and *not* underestimation.

Disclaimer: I have originally estimated this post will take ~33 min but it took me ~240% more time… (this is why I prefer to tweet lately ;)

Six annoying facts about our (/homo sapiens) planning or estimation “skills”:

  • We are basically optimistic and have strong desire to please
  • We tend to have incomplete recall of previous experience
  • We tend to have focus bias when estimating e.g. estimating only the coding phase estimations which is only ~14-37% of the required work
  • We tend to postpone what we can a.k.a. “The Student Syndrome”  (Eliyahu M. Goldratt, Critical Chain)
  • “It always takes longer than you expect, even when you take into account Hofstadter’s Law (Douglas Hofstadter, Godel, Escher, Bach: An Eternal Golden Braid)
  • We tend to underestimate task completion times – a.k.a. The planning fallacy

Overestimation is Overestimated

“The developers say that this project will take 6 months… I think there’s some padding in their estimates and some fat that can be squeezed out of them…we also need to instill a sense of urgency in the development team… so I’m going to insist on a 3-month schedule. I don’t really believe the project can be completed in 3 months, but that’s what I’m going to present to the developers. If I’m right, the developers might deliver in 4 or 5 months. Worst case, the developers will deliver in the 6 months they originally estimated” (Does this ring *any* bell???)

Four reasons on managers tendency to “fight” overestimations:

  • Underestimation (see above :) | “The feature estimation seems bloated” | “Isn’t it 20 min work?” | “Just add another index to the %$^&ing table?” | “It is only one more button…”
  • Unreasonable time constraint | “We need this feature yesterday” | “Nothing is impossible for the man who doesn’t have to do it himself” (A. H. Weiler)
  • True belief that Parkinson’s “Law” is really a law – “Work expands so as to fill the time available for its completion”
  • “The Student Syndrome”  (see above)

So… if feature estimation seems bloated, managers and other project stakeholders fear that Parkinson’s Law and the Student Syndrome would kick in and therefore consciously squeeze the estimates to try to control it (a.k.a. “The Parkinson’s Squeeze”) and when we squeeze where it isn’t needed or was squeezed already, it immediately lead to… UNDERESTIMATION (!!!)

Underestimation is Underestimated

Underestimation creates numerous problems – some obvious, some not so obvious.

  • Reduced effectiveness of project plans – Low estimates undermine effective planning by feeding bad assumptions into plans for specific activities. They can cause planning errors in the team size, such as planning to use a team that’s smaller than it should be. They can undermine the ability to coordinate among groups – if the groups aren’t ready when they said they would be, other groups won’t be able to integrate with their work. If the estimation errors caused the plans to be off by only 5% or 10%, those errors wouldn’t cause any significant problems but numerous studies have found that software estimates are often inaccurate by 100% or more (see above). When the planning assumptions are wrong by this magnitude, the average project’s plans are based on assumptions that are so far off that the plans are virtually useless.
  • Statistically reduced chance of on-time completion – Developers typically estimate 20% to 30% lower than their actual effort. Merely using their normal estimates makes the project plans optimistic. Reducing their estimates even further simply reduces the chances of on-time completion even more.
  • Poor technical foundation leads to worse-than-nominal results. A low estimate can cause you to spend too little time on upstream activities such as requirements and design. If you don’t put enough focus on requirements and design, you’ll get to redo your requirements and redo your design later in the project – at greater cost than if you’d done those activities well in the first place. This ultimately makes your project take much longer than it would have taken with an accurate estimate.
  • Destructive late-project dynamics make the project worse than nominal Once a project gets into “late” status, project teams engage in numerous activities that they don’t need to engage in during an “on-time” project… below are some examples when the important characteristic of each of these activities is that they don’t need to occur at all when a project is meeting its goals, these extra activities drain time away from productive work on the project and make it take longer than it would if it were estimated and planned accurately
    • More status meetings with upper management to discuss how to get the project back on track
    • Frequent re-estimation, late in the project, to determine just when the project will be completed.
    • Apologizing to key customers for missing delivery dates (including attending meetings with those customers).
    • Preparing interim releases to support customer demos, trade shows, and so on. If the software were ready on time, the software itself could be used, and no interim release would be necessary.
    • More discussions about which requirements absolutely must be added because the project has been underway so long.
    • Fixing problems arising from quick and dirty workarounds that were implemented earlier in response to the schedule pressure.

Tip of the day
Never intentionally underestimate. The penalty for underestimation is more severe than the penalty for overestimation. Address concerns about overestimation through control, tracking and *mentoring* but not by bias.

****************************************

More related posts (a.k.a. people who read this post also read these posts)

→ 8 CommentsTags: Management · Planning · Project Management · Psychology · Software Management

The Cone of Uncertainty in Pastel

April 18th, 2010 by Moti Karmona | מוטי קרמונה · No Comments

“The further a project progressed, the more accurate the estimates for the remaining effort and time became”
(Barry Boehm, “Software Engineering Economics“, 1981)
 
NASA also came to the same conclusion that in the beginning of the project life cycle (i.e. before gathering of requirements) estimations have in general an uncertainty of factor 4. This means that the actual duration can be 4 times or 1/4th of the first estimations…
 
I felt very free to add my own interpretation of the different point-of-views with cool pastel colors as a sneak-peak cool-beta-preview of my next post.

Make sense?
 

 

→ No CommentsTags: Development · Management · Planning · Project Management · Software Management

Just upgraded to WordPress 2.9 – Carmen

December 22nd, 2009 by Moti Karmona | מוטי קרמונה · No Comments

I have just upgraded to WordPress 2.9 – Carmen (named in honor of the jazz vocalist Carmen McRae) in less than 3 minutes…

WordPress 2.9 Highlights

* Global undo/”trash” feature
* Built-in image editor
* Batch plugin update and compatibility checking
* Easier video embeds
* Over 500 tickets, bugs and enhancements

→ No CommentsTags: Blogging · Simplicity · Tools · WordPress