Gigantt Blog

What's New in Gigantt

2012-04-22T14:57:00.000-07:00

We've focused on just one thing in this release - usability. After getting tons of feedback from new users we decided to put new feature development on hold and make the existing ones easier to use.

All New Design

The new look is much cleaner and more compact:

We've gotten rid of a few buttons that users didn't really need. Now there's tons of space for actually viewing your plan - space that used to be occupied by various panels and toolbars. And of course shiny new buttons for everything.

"The Bubble"

Gigantt is all about fast keyboard shortcuts for rapid editing, but over time we've really been neglecting the mouse, and it turned out that quite a few users aren't big fans of keyboard shortcuts. So we've really streamlined the mouse. Now a simple drag operation can both create tasks and draw arrows between them.

Here's how it looks in action:

Mac Support

Gigantt is now officially supported on the Mac and is tested on both Safari and Chrome.

There isn't much difference between the PC and Mac versions, except for the keyboard shortcuts. If you're a mac user you can print out the keyboard cheat sheet.

Tons of Small Improvements

Lots of stuff that you've been asking for and we've finally implemented. Here's a very partial list:

You can change the estimate of several tasks at once.
New keyboard shortcuts

R: Assign to a new resource.
T: Change the time estimate.
N: Add a note to the task.

Double-click outside any task (on the white space) to zoom-out.
Double-click on an arrow to "split" it (insert an intermediate task).

If you haven't already, go sign up.

Cracking a Safe with UX

2012-04-22T07:25:00.000-07:00

Your mission, should you choose to accept it, is to figure out the four-digit code of this safe with just one try:

With only four keys being schmutzed we know whoever punches in the code touches only 2, 5, 8 and probably 9. With four options we have just 256 codes to try.
However, since it's pretty obvious that digits aren't repeated in the code (otherwise we would not see as many as four dirty buttons), the number of combinations drops to just 24.

But can we use our UX expertise to crack this code in less than 24 tries (at most)?

First, the rules should be made clear. In this keypad you have to first press the key button, then the four-digit code, and then the key button again. Now let's have a crack at it.

Which digit is first? That's actually really easy to guess using Fitts' law.

Fitts' law is about ergonomics - how people use machines. Specifically it's about pointing. What it says sounds almost trivial: the bigger and closer the target, the easier it is for us to point to it accurately. So if a button is bigger, it's easier for us to point to it. The same goes if a button is closer to our finger - the farther it is, the less accurate we are at pointing to it.

We can deduce from Fitts' law that the larger the dirt circle around a button, the more the finger had to travel to get to it. The button with the biggest circle of dirt is clearly 2. This means the finger that presses 2 travels the farthest distance from its initial location. Because the distance is so great the finger usually misses it quite a lot, hence the large dirt circle. So its likely that 2 is the first button pressed. The finger has to start from the key button, then travel the greatest distance to 2, and then continue to some other key.

Great.

Code thus far: 2 _ _ _

We're down to 6 possible combinations. But can we narrow it down even more?

Which button is next? If 8 were the second digit, followed by 9 or 5, we would expect to see a bigger dirt circle around 8 than around 5, right? Because the distance from 2 to 8 is greater than from 5 or 9 to 8. Clearly, then, the next key is 5. And now there are just two left.

Code thus far: 2 5 _ _

So which is the 3rd button: 9 or 8? 9 has the smallest dirt circle around it, so it stands to reason that the finger travels a very short distance in order to get to it. This seems to suggest that we need to press 8 and then 9. But if that's the case then why is the circle of dirt around 8 bigger than around 9? Both are pressed after adjacent buttons, after all, so shouldn't we expect them to have the same sized dirt?

Time to think about ergonomics some more. Since the key pad is mounted on a door we need to raise our hand in order to tap on it. Now it's a bit easier to move your finger sideways in this position than up and down. Why? In order to move your finger vertically you have to move your elbow, which requires your shoulder muscles to go to work. Those are some big joints. In contrast, move between horizontally adjacent buttons your elbow can almost stay in place, with only the rest of your arm moving. Try it. I'll wait for you.

See? So vertical moves are harder, and therefor we can expect buttons that are pressed after horizontally adjacent neighbors to have smaller dirt circles than those pressed after vertically adjacent neighbors.

So it's 8 and then 9.

Code: 2 5 8 9

Just one attempt.

Conclusion: Fitts' law works all over the place, not just in computer GUI.

Also: clean your damned keypads.

We used Fitts' law when we designed our new Bubble Menu interface:

The buttons inside the bubble are relatively big and since the bubble opens up wherever you start dragging from the buttons are always close to the mouse's cursor. Close and equidistant.

So go sign up for Gigantt. Active beta users will enjoy a lifetime discount when Gigantt leaves the beta phase.

Feature Sneak Peak - "The Bubble"

2012-04-08T07:41:00.000-07:00

We don't normally do this, but "the bubble" turned out so cool we wanted to share it with everybody even before it reaches production.

Have a look.

Why geniuses are overrated in software engineering. Knowing that > knowing how.

2012-04-01T07:56:00.003-07:00

Knowledge is underrated in software engineering. We value problem solving skills and quick learning a bit too much by comparison. Let me explain what I mean.

Being smart means you can pick up any programming language in no time. You can get to know new technologies quickly and do a good job at using them. But that's not enough. In fact, since learning how to do stuff is so easy these days you don't really get to accumulate a huge advantage over others in this way. Everybody knows how to google, and these days googling takes you 90% of the way to learning anything you need to learn. Sure, smart people learn faster. But how much faster?

Let's see.

One constant (sort of) is the time is takes to read up on something. Even a genius has to actually RTFM, and if the manual has a few hundred pages then it's going to take a bunch of hours to read it. No getting around that. This genius would probably understand it all immediately and realize the implications and possibilities of this new knowledge in a deeper way, while us ordinary folks would struggle a bit. True. Maybe we would need to find a better written text - something that's easier to understand. Maybe we need a few more examples. The bottom line, though, is that it's going to take a non-genius three days instead of one day to reach roughly the same level of knowledge. 3x as fast. That's about it.

Put another way, geniuses are real good at learning how, and that makes them more effective. But the reality of software engineering is that we don't spend the entire day every day learning how to do new things. Most of our time is spent applying this knowledge, you know - actually creating software. So being 3x as fast at learning new stuff probably means you get the job done 15% faster over all. (Why 15%? Whatever, the point is it optimizes a smaller portion of the total work-time as an engineer).

So how come we value IQ so much when we evaluate software engineers? Most of us aren't doing rocket science. There's a minimal brain span you need to have so you don't make stupid mistakes and you can actually understand what you're doing. But beyond that it seems that all this brain isn't really making a difference.

Here's the reason. I think.

What googling doesn't really help you with is knowing that there's something you need to know. It boils down to search being a function that takes a parameter - you search for something. If you have no idea that something even exists then you can't really search for it. To learn that something is possible you need to engage in active exploratory learning. You need to be curious about stuff, talk to people, go outside your narrow field of work and generally fill you brain with facts about the possibility and existence of things.

In short, knowledge, not just know-how, is key. And the kicker is that knowing about something isn't that hard. Don't need to be a genius to remember that you read about somebody who did something. Then you just need to look it up and apply it. This sort of superficial, broad knowledge makes a ton more difference than know-how. Why? Because so much time is wasted trying to solve problems that have already been solved. Being a genius can really be a hindrance to productivity in this sense. Brainiacs often underestimate the difficulty of problems, or just seek out challenges because they're getting bored. This is costly. You don't want a genius reinventing new kind of scalable database for your terabytes of data. You want somebody who's heard of Cassandra or CouchBase and follows the High Scalability Blog. That's the guy you want.

Bottom line, I would value someone who's heard about every new technology or technique much more than someone who would be able to utilize it 15% more efficiently. When the playing field for learning how is pretty much flat, thanks to Google, we can differentiate ourselves and compete by accumulating knowledge. Sounds a bit trivial when put this way, but really this sort of broad knowledge is just not something that hiring managers are focusing on these days. The mantra seems to be that smart people could learn anything, so why bother testing their knowledge - that would be like evaluating a new car model based on where this car has been driven. Kind of pointless, right?

No. It's not like that. It's not just about how fast you can learn - it's more about how much you have learned. It's not just about how deep your knowledge - it's more about how wide it is.

So width more important than depth and speed.

That's what she said.

Speeeeeeed!

2012-03-18T08:54:00.001-07:00

Today's release of Gigantt is all about performance. Navigating inside plans, zooming in and out - it's all real snappy now. Try it out: http://www.gigantt.com

Flash Optimization

So what did we actually do? Programmers, read on. Humans, feel free to skip the rest of this post and move straight on to trying it out.

Our recent releases have been focused on adding functionality and the whole thing just got very heavy and bloated. Memory was leaking because apparently Adobe Flex isn't really meant for creating thousands of recursive controls over and over again. The worst part was the latency - if you've navigated into a task that contained many sub-tasks it would take them a while to load which was very frustrating and it slowed you down. That dog won't hunt. We learned that one of the slowest things you can do in Flex is to add and remove elements from the display list. So now we don't. We recycle and hide unused elements instead of adding/removing them. That also took care of the memory leaks, since apparently we cannot rely on Flex to properly dispose of unused objects (even [sigh] when the Flex Profiler itself shows no paths to those objects from the GC root).

Rendering tiny zoomed-out sub-tasks was rewritten in lower-level Flash graphics (as a C++ developer it sounds odd to me - "low level Flash"... but I'm getting used to it). This approach worked great when we implemented Team View so we adopted in the other views as well.

So how noticeable is the difference? Quite noticeable. We measured how long it takes to drill down from the top of a large plan to the bottom-most "leaf" task and it took about one third of the time. So roughly 3x as fast. But that's mainly because the built-in animation simply takes its time (about 400ms) - without it navigation just seems jumpy and weird. When we profiled just rendering time we saw a 10x improvement.

Hopefully you'll notice this too.

What are we doing next month?

2012-02-26T06:39:00.003-08:00

I'm happy to announce the latest version of Gigantt. The long anticipated and much requested "Team View" is now live. Finally you can see what every team member is doing at any given time.

You can see Team View in action in the following two-minute video:

Learn more on our help wiki.

If you think Team View looks awesome you can sign-up for the private beta program. More invites will be going out in about two weeks.

Screenshots Straight into Imgur.com

2012-02-14T10:31:00.000-08:00

If you tend to use lots of screen-shots (like me) you should probably know SnagIt. It's the number-one screen-shot application for Windows. It takes over of your PrintScreen keyboard button and when you click it you can then choose the screen area to capture.

If you create lots and lots of screen-shots you can configure SnagIt to automatically write the files to some directory. But what if you always need to upload these image files to some public location?

That's where imgur comes into play. They'll gladly host your image files and give you permanent links to them. The cool thing about this is that they have an API. So, yes, you've guessed it, you can connect SnagIt to imgur!

Here's how:

You need Python (if you're not a programmer, this isn't for you, sorry...)
Save this script somewhere in your machine: https://gist.github.com/1828787
Then configure SnagIt to output into this script as a program. You might need to wrap it with a CMD file, depending on your local python setup.

That's it. Now when you snag a new screen-shot it will automatically be uploaded to imgur and the URL will be copied into your clipboard. PrintScreen -> Paste URL into your blog or Facebook status -> Bang, you're done.

A Programmer's Guide to Successful Outsourcing Online

2012-02-07T04:07:00.000-08:00

Gigantt outsources much of its work online through sub-contractors. If it's not part of our core intellectual property then we get someone else to do it. It's much more cost-effective. Every full-time employee gets a discretionary outsourcing budget used to get work done, no questions asked as long as it's within the following guidelines.

1. It's amazing how much you can actually outsource effectively once you do the mental switch. It ain't about the jobs you can't or don't want to be doing, it's about the jobs you shouldn't be doing.
Let's say you need to learn about a new technology and whether or not integrating it into the product is a smart move. The auto-didactic hacker approach would automatically lead you through the path of reading manuals, searching forums, asking questions online and generally satisfying your intellectual curiosity through hours of reading and playing around with new toys. Now let's say you value your time as a developer at $100/hour (it can actually be much more). If you spend only three hours figuring out a new technology - that's $300. But why not pay someone who's already an expert at this technology to tutor you on Skype for one hour? That person probably values their time roughly the same as you do. You just got the best tutorial you could get and saved $100 in the process.
Notice this particular example only really works if people don't need to get their boss's approval for every job they wish to outsource. Not many people would be comfortable approaching their boss and asking him to pay for an hour's worth of tutoring, but often that's the most cost-effective thing to do.
The point is to be mindful of the possibility of outsourcing and really think twice before deciding to do something on your own.

2. Get to know oDesk. It's probably the smoothest running outsourcing engine out there, with more than a million sub-contractors. Posting a new contract takes us no more than 5 minutes now. And, if you know what you're doing, deciding on a candidate and hiring can take about 10 additional minutes. That's about 15 minutes we can put down as cost-of-transaction. At the above rate that's $25 overhead. Naturally this means if you can do the job yourself faster than that then you should. But most jobs take more than 15 minutes.

3. Insist on superb English communications skills. That is, of course, assuming English is your work language. This cannot be stressed enough. 90% of outsourcing success and failure is attributable to communication quality. If you aren't speaking exactly the same language, literally, it's not going to work. Be very selective when evaluating candidate's CVs and cover letters. We automatically disqualify based on the tiniest spelling, punctuation, grammatical and style errors. If a candidates can't be bothered to proofread his own profile then you're probably not going to get a 100% perfectionist performance our of them.

4. Plant some non-obvious requirement into your job post. You need to be able to identify (and disqualify) those that send out applications en-masse without really investing time into their cover letter. We sometimes ask for a sample of their English writing work in the job description, even if the job itself is completely unrelated to writing. If candidates don't attach such a link they obviously either didn't read the job description (don't care enough) or can't follow simple instructions.

5. If it's a long-term job or requires any amount of talking over phone or Skype then be sure you can understand the person's accent. Many sub-contractors, especially in Asia, are just not that easy for westerners to understand. It's a matter of accent and also a matter of connection quality - Skype can really a problem in this respect. So do a Skype interview. It can be as short as five minutes. Again, this often does not apply because some jobs require no Skyping to get done at all.

6. Use an hourly rate instead of a fixed-price for the job. Don't worry so much about people billing too many hours. That never happened to us and we've employed dozens of people. Using an hourly rate even for stuff that initially seems like a very clear cut and properly estimated job has a few advantages. Unless your job description is superbly clear and comprehensive, realize that you might not get exactly what you asked for. People will misunderstand and then have to repeat work for you, and if they start losing money while doing so you'll get hurried, resentful work. Unless you've worked with the particular sub-contractor before and he's doing the same exact job again you can't really trust their fixed-price bid to be spot on. The point of outsourcing is to not worry about the job, and this means you have to employ people who are willing to redo and improve their work up to your standards, which may be higher than theirs.

7. Be very clear about I/O. It's just like design by contract. Specify exactly what your input is going to be and how you expect to get their output. It can be trivial stuff like which file formats or applications to use. But it can also be about progress updates - how often do you expect them to occur, etc. Our job descriptions often ask sub-contractors to spend not more than X hours initially on the job, then stop working and report to us with their progress so we can evaluate it and adjust expectations.* The clearer you are about breaking down the work into milestones and receivables the less you'll be disappointed.

8. Coordinate expectations about the amount of work that needs to be done and realize that sub-contractors usually work on more than one job at a time. Specify exactly how many hours per day or week you expect them to work. If the work is occasional in nature then coordinate expectations and realize they might not always be available on a day's notice.

9. Consider over-hiring. Need some data-entry work to be done? Hire two or three people for the same job (usually $2-$3 an hour - very cheap in western standards) and see which one performs best on a smaller initial milestone - that's the one you keep for the long term. Be honest and upfront about the fact that work will start on a smaller evaluation basis. Let people prove themselves to you by working (and getting paid). The cost of hiring and firing is very, very low and we developers are accustomed to the very opposite (recruiting takes forever and mistakes are very costly).
If the work is repetitive and error prone, people will become fatigued and make mistakes, especially the 17th time they basically do the same thing. In such cases it's perfectly reasonable to hire more people for the job than strictly necessary. Redundancy is your friend because it's unlikely two people will do make the exact same mistake. It also helps with the issue of availability mentioned earlier.

10. Finally, be respectful and courteous. Yes, hiring and firing on oDesk can take five minutes and have little implications for you, but the people working for you deserve your respect, even when they occasionally don't live up to your high expectations. It sounds silly to have to even mention this as a tip... Outsourcing online usually happens across cultural boundaries and not everyone has the same work attitude, conversational style and politeness (Israelis, I'm looking at you!). So be extra nice.

---------------------------------------------------------
* This is actually a tip by Tim Ferris. Read his book, or at least the chapter on outsourcing. Another great chapter on outsourcing can be found on http://www.startupbook.net/.

Clear Browser Cache - a Saturday Project

2012-02-04T06:01:00.000-08:00

UPDATE: Because of embedded iframes in this post I highly recommend you read it out of your RSS reader.

Woke up today with an idea that must have its day. So, you know how web applications sometimes ask you to clear your browser's cache. It's the equivalent of "turning it off an on again". A general cure for everything.

But how do you explain to very simple users the steps to clearing their browser cache? Most users probably don't even know what sort of browser they're using. You need to detect it for them and present them with step-by-step instructions (with screen-shots), and practically nobody does this. It's just too much work.

We need a website that does just this - it detects your browser and shows nothing but the steps to clear your cache. Web developers could then just refer to it instead of recreating it on their own over and over again. They could even embed it as an iframe...

So this is my Saturday project. Let's see how far I can get today.

09:30 - Wrote the into above and checking online that nobody has already done this.

09:31 - This can be a totally static website with just Javascript to detect the browser. So it can be hosted in its entirety from S3. I always wanted to do that. Let's read up on how.

09:38 - Seems simple enough. Just create a HTML page and upload it to a new bucket on S3. Then turn the "website" switch in the bucket properties.
Created a bucket called "clearcache" (I already have a Amazon account).
Created a new local directory for this project on the best source control system - DropBox :)
Created a hello world html file called index.html
Now just s3cmd sync . s3://clearcache

Oops! Amazon says access denied when I tried to view the website at http://clearcache.s3-website-us-east-1.amazonaws.com

Giving "View Permissions" to the bucket doesn't seem to solve the problem.. but making the index.html file public does. But that's no good - would I need to do this for every file I upload?

09:56 - Time to RTFM...
09:57 - Argh.. they ask you to create a "bucket policy" and upload it. Common, Amazon, couldn't this have been a checkbox?
Ok, so the site is up.

10:10 - Let's give it a nice name like clearcache.gigantt.com. Amazon suggest adding a cname in the domain DNS records.
That doesn't seem to work. Gives a permission error..
The manual says the bucket name has to be the same as the domain name.. rats!
Ok, let's rename the bucket to clearcache.gigantt.com
Great, now I get to wait 30 minutes for the dns cache to expire. I guess that's a good a time as any to eat breakfast.

10:42 - And we're back. And the new cname works: http://clearcache.gigantt.com/
Time for a little design.
This website should be dead simple. You visit it and all you see is instruction on how to clear your browser. So we need some javascript that can detect browser, OS (because screen-shots will look different on each OS) and browser version. Probably also language, but let's start with just English for now.
I'm thinking the index page should just contain enough js to determine the right version and then fetch the appropriate html. So it's basically a dictionary of browsers identifiers to HTML manuals. Which also means we need to show a default in case we don't have a manual for the specific browser at hand. That can probably be some 3rd party web site that explains the same steps but doesn't detect the version.

10:53 - Cool. There's a JS library that does browser detection pretty well. We'll make our index.html file link to it and also add JQuery just for good measure.

10:58 - Here's our skeleton HTML. We'll worry about validation later:

It prints:

Your Browser is Chrome 16

11:06 - Let's figure out the dictionary we're going to use. I want it to degrade gracefully, so if we have instructions for FireFox but maybe not the specific version in question then it's probably better to show instructions for some other version than to fallback to the options of last resort (linking to an external page). So the keys need to be Language / Browser / Version / OS - in that order. This order makes sense because the same instructions on different OSs are much more similar to each other than instructions for different browsers on the same OS....

First let's shove all the JS into one main file:

12:10 - Here's main.js. It looks for the best match and tries to load the relevant instruction manual:

12:23 - Now I just need to populate the directory structure lang/browser/version/os.html with a few initial manuals. Let's create the first one for Chrome, then style it a bit.

12:48 - First manual for Chrome is ready. The html page itself has no styling at all:

And it looks like this:

So obviously it needs some nicer styling.

12:53 - Let's add CSS to this thing. First, we want it to be mobile friendly from the get-go. So we'll keep the snapshots as narrow as possible and the design itself should be dead simple. Just a centered narrow page with ordered instructions.

Nothing too fancy.

13:55 - Let's DRY things up. I really don't feel like writing the same html template for each manual. Only three things change, basically: the logo, the instruction text and the image that goes with each instruction. Everything else can and should be generated automatically.
We want the entire manual HTML file above to be reduced to the following JS snippet:

14:34 - Here's the code that generates our HTML from the above JS dictionary:

Even the image names are auto-generated (image1.png, image2.png, ...) and each browser has its logo specified just once. Here is the resulting directory structure:

14:39 - Lunch time. Afterwards I'll add Firefox and IE.

15:48 - Firefox 10 and IE 9 are done. Now it's just a matter of adding more browsers and OSs. But I think I'll offload this to an outsourcing contract on oDesk.

That was fun. Visit http://clearcache.gigantt.com to see the finished product.

Sources: main.js, index.html, manual.css

How to Shampoo Your Employees

2012-01-26T02:47:00.000-08:00

I joined the Israeli Defense Force in 1997 and served the mandatory three year period as a software developer. Army service usually consists of three* phases: first year - you learn the ropes, second year - you get things done, third year - you teach the new guys.

The Hebrew term for this period where the veterans teach the newcomers is called "the overlap", which, incidentally, is exactly the same Hebrew word for "shampooing". Don't ask me why. It's weird. So the veterans shampoo the newcomers and thus the wheels keep rolling from year to year.

Something similar happens in software companies. The term "training period" doesn't really capture the essence of what really goes on. Newcomers are often extremely well trained at their job already and all they really have to go though is a getting-to-know phase. Getting to know the product, the team, how things usually work. You know, shampooing... English speakers, I suggest you adopt this term.

One problem that plagues many software teams is knowledge hoarding. You all know someone like that. Someone who really loves being the most informed. Some veteran to whom everyone comes with questions. I guess some people think that makes them more valuable. I think they should be fired as quickly as possible because I've yet to see someone like that actually mend his ways.

The perfect team player, on the other hand, is someone who's powerful, effective, but also completely replaceable. Like a CPU core. Your machine has four of them. They're expensive and they get things done. But lose one of them and your computer will keep on going, just a little slower. There's nothing it won't be able to do with just three cores, and when you plug in a new one things will go back to normal.

Now here's the secret for ultimate shampooing.
Ready?
Take the third year and the first year and squish them together. In other words, when a newcomer arrives on the scene his first order of business is to write the shampooing plan for his replacement. If one was already written, he can improve and augment it as he picks things up.

That's a great general principle, and it applies not only to newcomers, because in our line of work we constantly learn new things. Keep nothing solely in your head. Be mindful of what you learn, and document it in a discover-able, public way. Not only the idiosyncratic quirks of your project, but also tricks of the trade, theoretical knowledge of the problem domain, mapping out who knows what and where to find stuff. Everything.

Gigantt has recently recruited a QA manager. Until now the QA team had to deal without one. His first job is to write our QA Manager Handbook, which ought to include 100% of what his successor would have to read in order to get going. Being completely replaceable as a team member almost makes you irreplaceable, because so few of us are actually that minded towards knowledge sharing.

_________________________________________________________

* Actually everything in the army consists of three parts. It's... exhausting.

Handwritten Signatures in MS Word

2012-01-01T08:17:00.000-08:00

How many times have you had to print a Word document just so you can sign it and then fax/scan it back to someone?

Ideally you should be able to add your signature directly to the Word document, and then print it to PDF or just send it. This turns out to be really tricky to do, but today I've cracked the problem.

Typically, you get a document looking like this:

How do we add a signature? Well, we could sign our name on a white piece of paper, scan it and just plant that image in Word, right? Not quite. When you scan an image (or take a photo with your iPhone for that matter) you get a JPEG image, and JPEG images do not support transparency.

Here's what a scanned signature looks like right off the scanner:

First thing you'll notice is it's big. If you want your signature to look legit when the document is printed you have to scan it at at least 300 DPI. Your computer screen, however, has a resolution of about 75 DPI normally. So if you add this photo to Word you'll have to re-size it down. The end result is something that looks like this when printed:

Terrible.

First of all, the white background of the signature photo is opaque. As a result the image hides the "Signature" text and the line we're supposed to sign on. We want to somehow make the white areas transparent, so that when we plant the signature onto the page it looks as if it was drawn on by hand, not plastered on with a computer. This can be done with image editing software, such as Paint.NET (free), if you know what you're doing. The resulting image must be saved in a more appropriate image format - one that supports transparency. Best is PNG.

But even that's not enough. The end result, when printed, still looks terribly fake. Here's a close-up version to illustrate:

See how pixelated it looks? When you print this on a piece of paper you definitely see the difference. Why is this happening? Didn't we take a hi-res scan of the signature?

Why? Because Word is dumb. When you scan an image in high resolution (e.g. 300 or DPI, same as a good printer) the image you get on your computer is big. When you then resize the image in Word to fit the signature space, Word just prints the picture as it appears on screen (i.e. in 75 DPI). It's not smart enough to say "this picture is scaled down, but I do have the original high-resolution at hand, so I can send it to the printer at 300 DPI".

Also, what if we want to print at 600 DPI, but our scanned image is just in 300 DPI? Ideally we'd want a vector image of our signature, not a raster image. Vector graphics nowadays is usually saved in the popular (and open) SVG format. And you can find services online that will try to convert a raster image (e.g. jpg) to SVG. Only one problem with this: Word can't handle SVG. So there's one more hoop to jump through.

Here's what you need to do to take a scanned image of a signature and convert it to something you can actually add to Word. You need just one application - it's called Inkscape and it's a totally free vector graphics application.

Take a white A4 paper and put your signature on it using a nice, thick pen.
Scan it at 300 DPI (grey-scale is fine, too).
Crop out everything but the signature. This can usually be done in the scanner program itself if you do a pre-scan. But you can also do it with MS Paint.
Save it as JPG.
Open Inkscape.
Drag and drop your scanned JPG into Inkscape.
Select the image in Inkscape and choose Path -> Trace Bitmap from the menu.
Use "Brightness Cutoff" with a high threshold (over 0.9) and press Ok.
It will create a vector version of the signature and place it directly above the image. Drag it away to see the difference between the two.
Feel free to play with the threshold until you get a good reproduction of the original image.
Now select the original image and delete it (DEL).
Select the good vector version and do File -> Document Properties -> Fit page to selection.
Now save as EMF.
You can now drag and drop this EMF into Word. Make sure the Text Wrap property of the image in Word is set to "In Front of Text" and then just place it over the signature space.

Here's a close-up of the raster vs. vector images side by side in Inkscape:

Here's just one letter scaled way up, just so you see how good the vector version is:

And here's what it looks like in Word:

Keep that EMF file at hand. No more printing, faxing and scanning.

The GitHub Job Interview

2011-12-26T23:19:00.000-08:00

One interview is never enough

to find if the candidate's up to snuff

takes two or three more

job interviews before

you can tell if the CV's a bluff

How the hell do you interview a start-up CTO? Finding software developers is hard enough, but a start-up founder can't take any chances when it comes to hiring developer #1. So, what, five interviews? How much can you talk to someone before you know what's like to work with them?

It's apparent to anyone who's done this that the marginal value of yet another interview approaches nada after two or three sessions. Some people are just good at being interviewed and can charm the quark off a hadron, but when you start working together all kinds of stuff rises to the surface. None of this is news to experienced hiring managers. Everybody knows that working together with someone is the ultimate job interview. If only you could try people out before hiring...

Bad Solution

Some hiring managers try to do that. Sort of. They hand out programming exercises and expect candidates to not mind wasting their time developing nonsense code just for the sake of the interview. This sucks. I never do that, and I'd never play along if someone asked me to. It's plain unfair. Worse, however, are those that actually offload real work onto candidates. Yea, that happens. People are expected to work for free before being hired.

You might say, just hire. Let someone work "on probation" for a short period and if it works out, great. If not.. well, it doesn't really work out that great for them. Being rejected after two weeks of work doesn't look good on anyone's CV. Moreover, the time you have to spend with new employees getting them up to speed with your code-base, development guidelines, the product and so on is just too much of an investment. And at the end you're likely facing a disgruntled ex-employee with access to your source-control system. Yikes.

Awesome Solution

That's why I'm advocating the GitHub job interview. Open-Source projects are a fantastic way to collaborate with people you don't know too well. And GitHub in particular, with its ease of forking and pull-requests is just the best (and biggest) platform for open-source collaboration.

Here's what you do. You come up with a cool idea of an open-source project. This becomes your company's development sandbox. Candidates are asked to then contribute to the project in some way. You want to see them code? Ask them to develop a module. You want to see them tackle a bug? Ask them to choose one from the bug-list. This works for every aspect of development work. You can design features together. You can gauge their communication skills. You can see how well they handle reviews. You can ask them to document their work and see how well they can write. But above all, you're not taking advantage of anyone, and true developers probably won't mind investing time into an open-source effort.

Choose your GitHub project wisely. It should be something relatively fun. It ought to use the same technology stack your company uses. And it should be relatively simple to grasp, because the point is not to be investing too much time training people you're not yet hiring.

Not all developers have existing online projects they can point to when you're interviewing them. So make one for them. You avoid hiring and firing. You reduce risk by investing less time and not exposing your IP to candidates.

This is what Gignatt will be doing, now that we're hiring our first employees. Stay tuned for details on our open-source project.

A Self-Referential Demo Video: How To Plan Projects with Gigantt

2011-11-14T11:12:00.001-08:00

We've been getting lots of helpful feedback from our beta users, and one question came up a few times: how do we plan a project?

That's actually a great question. While using the application may be very easy, it's not often clear, when faced with a blank slate, how to start planning a project.

So we made this short instructional video. It's three-minutes in length, but it tries to cover a lot. Not only how to get started, but also best practices and techniques we've been learning by using Gigantt ourselves.

The video is doubly awesome because it's self-referential. You'll have to see what that means yourselves...

Don't forget our ever-growing help wiki.

Waze's Next Killer Feature

2011-11-09T23:27:00.000-08:00

This post is completely off-topic. It's not about project planning. It's about the best damn GPS navigation software out there today - Waze.

Waze is awesome because it uses information gathered from all its users' smart phones to learn where traffic is jammed and route drivers accordingly using the quickest route.

But there's one thing I always miss when using Waze - it doesn't tell me where I can park. Sure, adding a parking lot layer over the map is sort of a solution. Many competing products do this. But in some places [cough]Tel Aviv![/cough] this is simply not enough because there are waaay too few parking lots.

Where do I park???

So here's what Waze's next killer feature could be: crowd-sourced parking. As a user I would definitely pay money to know where the closest publicly available parking spot it. Waze could set up a whole economy of parking spots: when you leave a spot you "check out" with Waze. If you're looking for a parking spot you hit the P button and Waze directs you to the nearest one. Users could accumulate parking credits when they check out and another Waze user takes their place.

I hope somebody there reads this.
Anywayz, Gigantt ♥ Waze.

Cheat Sheet

2011-10-31T07:44:00.000-07:00

All you really need to know to get started with Gigantt is ENTER for a new task and INSERT for a new child task. But power users quickly become thirsty for more keyboard shortcuts, and Gigantt has one for every possible action.
Gigantt's help wiki now contains a keyboard shortcut cheat sheet you can download and print.

hi-res

Gigantt Presenting at TechAviv

2011-10-21T08:40:00.000-07:00

Gigantt will be on stage Wednesday at the next TechAviv Founders Club conference.
Come watch and mingle - places are limited, so better register now.

Help!

2011-10-14T09:44:00.000-07:00

Gigantt's Help web site is now up. It's in the form of a wiki. A true wiki; meaning anyone can edit it.

Right now it contains mostly articles explaining the existing features, keyboard shortcuts, FAQs, that kind of stuff. But I do welcome contributions from users.

Team Edition

2011-10-08T23:59:00.000-07:00

Today, after way too many weeks of testing and improvements, Gigantt's Team Edition is live. You can finally assign tasks to people (or other resources) and enjoy Gigantt's smart goal-based task scheduling.

Here's what the new version looks like:

A few new things to notice. All of these tasks are assigned to Cosmo Kramer, as evident by the watermark on the bottom-left corner. It tells us that Kramer is in charge of this part of the plan, and that any new task created here will be assigned to him by default.

If we decide to add another task here and assign it to George Costanza, we'll see his name on the left of the task:

All the other tasks belong to Kramer - the default owner of tasks in this area - so there's no point in showing his name beside each and every task. That's why only George's name is shown.

To reassign a task just click on the left side-panel and you'll see this popup where you can select any team member:

You can also reach it with the keyboard - Tab will reach the button and Enter will open the panel.

The start & finish dates of each task is shown in the time-bar above:

There's now a wider range of estimates that you can choose for each task, including even a one-minute estimate (useful for check-lists). The estimate panel has an array of buttons so that estimating a task is just one click for ultra-fastness:

Important note: as part of the beta-ness of this version there's still no UI to add/remove members from your team. That's in the next version. No worries, though, just write to support@gigantt.com and we'll do it for you.

Prioritizing Goals in Gigantt

2011-08-12T22:22:00.000-07:00

Should we invest time in infrastructure or focus on shipping the next big feature? Should the QA team work on "Product A" or "Product B"?

Managing a complex work plan that spans multiple projects and teams means always being able to decide what's more important. And there's always a decision to be made. Telling your development team to focus 35% of their time on one project and the rest on another is a sure recipe for both projects not finishing on time. Keep it simple, break the plan into smaller chunks and decide what's more important.

This is how Gigantt tackles prioritization. Instead of maintaining complex resource allocation schemes, users of Gigantt define goals and prioritize them. A goal in Gigantt is just any task in the work plan. When you mark a task as a goal, Gigantt analyzes the entire work plan and considers all the tasks that have to be completed for the goal to be reached. For you nerds, it's like a reverse DFS of the work-plan graph. Okay, enough nerd talk, let's see an example.

Kramerica Industries has two products: Widget and Cajiggre, and there's a work-plan for a few weeks ahead.

Jerry is in charge of Widget and Kramer is in charge of Cajiggre, and as long as that's the case there's not much to prioritize. Work happens independently and in parallel. Things become more interesting when there are shared resources between products. So let's throw George into the mix as QA Manager. George has to test each version of each product before it can be shipped, and there's only one George... Let's see how each product's plan looks now.

Jerry's plan looks OK. He does the development and George does the testing (and shipping) right after each version is finished:

But Kramer's plan has a few delays in it. For example, George is busy testing Widget 1.0 when he could be testing Cajiggre 2.0:

At which point a decision has to be made, which product is more important. Since Widget appears before Cajiggre in the work plan, Gigantt will automatically give it preference when assigning resources. Whatever appears on top is considered higher priority. This is true for simple tasks as well as for whole projects and it's the simplest way to prioritize in Gigantt. But what if Cajiggre 2.0 is actually a top priority for the company? We need finer-grained control over priorities, not just between products but also between individual versions of each one. We achieve this by marking all of the ship tasks as goals.

Just toggle the little star icon for every task that should be considered a goal:

If we then click on (prioritize) we see an ordered table of all the goals in our work plan:

If we drag "Ship 2.0" to the top, as the video below shows, all the tasks leading up to "Ship 2.0" get rescheduled so that "Ship 2.0" completes as early as possible.

Same thing can be done with individual tasks, not just entire versions of the product. Since a goal is defined as everything that must happen in order for a given task to finish it's entirely possible to define multiple goals in the same projects. Notice that goals can also overlap (share tasks).

first task is shared by both goals and thus has top priority (red)

Whenever there's any contention about a shared resource, managers can easily define any task as a goal and prioritize it to settle the dispute. They can also play around with priorities to see how much it effects the finish dates of each goal. Instead of allocating resources in advance to various teams and then fighting over who "owns" the lab this week, only goals are prioritized and everything else is derived from that. Prioritizing goals is less confrontational than prioritizing teams or entire products.

What I like best about Gigantt's goals is how clearly the organization's priorities are conveyed to the teams. It's hard to get confused by that table above. Everybody knows where their efforts should be focused.

A Duck!

2011-07-24T08:33:00.000-07:00

I believe it was the comedy genius John Cleese who once said that the funniest animal is the duck.

Today I took a day off from working on resource scheduling algorithms and decided to write a fun little tool that I've been needing. So, ever needed to copy paste some text from your PC to your iPhone? Sending yourself emails is so lame. I wanted something that was fast, requires no registration and nothing to install on my mobile phone.

I give you Copy Duck:

You just paste stuff, take a snapshot of the QR-code, and then you see the same text on your mobile. Tested it on Chrome/iPhone but it should work on any modern smartphone (if you have a QR scanner app).

For the geeks: built with Google App Engine using Python, jQuery and Google Chart API.

Keyboard vs. Mouse

2011-06-23T09:02:00.000-07:00

When it comes to speed nothing beats keyboard shortcuts. First time users of Gigantt often start out by using the mouse quite a lot: clicking on buttons, zooming in and out with the mouse wheel. But once they learn the keyboard shortcut alternatives they usually adopt them and don't look back. Ten fingers are faster than two fingers.

Keyboard shortcuts also have the advantage of not cluttering up the screen with endless buttons and menus. But there's a UX price to pay - a steeper learning curve. For everything but the most obvious and intuitive keyboard shortcuts, like ESC (cancel), Ctrl+C (copy), there's no getting around the fact that users probably won't be able to guess which key-combo corresponds to which feature.

We still try our best to make sure keyboard shortcuts are as intuitive as possible. For example:

D - Mark a task as done
I - Implode a few tasks into one complex task
E - Explode a complex task into several tasks (the opposite of implode)
L - Create a link between tasks
DEL - deletes anything selected
INSERT - inserts a new task.

See? It all makes sense...

Until now nearly all mouse operations had keyboard alternatives. I say nearly because there's one thing you still couldn't do: select and manipulate arrows between tasks. Now you can.

The Up & Down keys still navigate between tasks according to their vertical order. If you want to select the arrow into the current task, just hit Left. You can then delete the arrow with DEL, insert an intermediate task with INSERT, and so on. If there are more than one arrow you can move between arrows with Up/Down as well.

These new shortcut solve a painful UX problem: switching input modes. No matter which you prefer, mouse or keyboard, having to constantly switch between them is a real speed bump. So rejoice, fellow typists! From this day on no feature is beyond your keyboard's reach.

Collaboration in Gigantt

2011-06-18T21:43:00.001-07:00

Today we're happy to release the first collaborative version of Gigantt.

What's changed?

Collaboration

Multiple users can now edit the same plan at the same time. It's also cool for the same user to edit the plan in multiple browser windows. However, Gigantt still doesn't support managing multiple resources (i.e. a team). That's our next major feature.
So what happens if two people make conflicting changes at the exact same time? Gigantt helps you avoid this problem by featuring a "freeze period". Basically, any task you modify and its immediate vicinity get frozen for 60 seconds. During this period only you can edit these tasks. Others have to wait for them to "thaw". Frozen items have a snowflake icon. If you hover over one you'll see who has been editing it and how long until it thaws out.

We think this approach to collaboration is better than simply letting people step on each other's toes and then asking them to resolve their conflicting changes.

Visual Clipboard

We got quite a lot of feedback about the way copy, cut & paste wasn't so intuitive. Now it's just like in Windows explorer, but you also get a visual clipboard window that shows you the contents of the clipboard.

The clipboard is also used for creating connections between remote items. To create a new link you select the source task and hit "L" (or the new link button). The task will be added to the clipboard in _linking_ mode. You then
select the target task and paste. That's it.

Performance

We won't bore you with all the details, but Gigantt is now wicked fast. Navigation is much quicker, even for very complex tasks, because sub-tasks are now rendered in the background (they sort of fade in). Auto-save is also much faster and so is every editing operation.

There are tons more improvements and fixes. But I'll leave it to you to find.

Keep sending us your feedback. It's really valuable to us and we do act on it.

T-Shirt Sized Estimates

2011-06-05T00:44:00.000-07:00

How long would it take you to write a Hello World program in a language you've never used? Minutes, probably. But how many minutes? three? nine? Asking for such precise estimates just doesn't feel right, does it? But if you pose the question like this "Would it take you less than 15 minutes?" it suddenly seems like an entirely reasonable question.

This, in a nutshell, is why T-shirt sized estimates work. There are other reasons, as well, but before we dive into them let's review what T-shirt sized estimates (TSE) are.

Agile development methodology has made the concept of TSE rather popular in recent years. The idea is to give rough estimates to tasks in the form of T-shirt sizes. Small, medium, large, extra-large and so on; you get the point. But what does "small" mean, really? This is pretty open to interpretation and each team may define these sizes in its own terms. Some associate a duration range with each size. e.g. S is less than one hour. M is between one and three hours. Some associate T-shirt sizes with points that are later added to an aggregate estimate. But in essence the idea is simple: instead of arguing over how many minutes or hours a task is going to take, let's just agree that it's small and move on.

Now there's a hidden aspect to this method. The sizes are limited and have an upper bound. No T-shirt is XXXXXXXXL. This is significant. People are terrible estimators of large efforts. We're less terrible with reasonably sized efforts. So using TSE doesn't mean we don't invest any real effort into estimating and just spit-ball "2 years!". It only means we're not fooling ourselves into thinking that giving a very specific estimate would improve our project's total estimate in any way.

In fact, overly specific estimates are detrimental to delivery on time. Estimation is a well researched area in psychology. People aren't just bad at estimating, they're also terrible at knowing how bad their estimate really are. That's why the vast majority of people consider their own intelligence or attractiveness to be above average (which is plainly impossible). Ask people to give a 90% certainty estimate and they'll consistently give a too precise answer. A well known experiment has been widely replicated in many classrooms. Students are asked when queen Victoria was born, and they need to give their answer in the form of a range of years (e.g. 1800-1900) that they consider to be 90% certain to be true. The goal of this experiment is to see how well people estimate their own ignorance/knowledge. Statistically, you would expect students to specify a range so wide that only 10% of the students would actually miss the correct year. But instead a much larger portion of the audience gives a wrong answer by selecting a too-narrow range. We're overconfident in our knowledge and underestimate our ignorance.

When you think about it, efforts estimates are really a form of self-estimation (uh-oh!). People are asked how long it would take them to finish a task. That's why most estimates are overly optimistic. It's tied to a host of psychological factors: over-estimating our own capabilities and skills, wanting to please our superiors (and ourselves) with a smaller estimate, ignoring potential unexpected surprises along the way, etc.

Here's how TSE solve these problems.

First, if you force people to round their answers they're more likely to factor some uncertainty into it. If you internally estimate a task at 40 minutes, but are then asked to choose between a 30 or 60 minute estimate, you'll suddenly remind yourself that 40 minutes doesn't really take into account various overheads or possible interruptions. And it's much easier to justify an over-estimation to yourself when it's someone else who's forcing you to round it up. Rounding up on a small scale is a good thing.

Second, by limiting yourself to small estimates you avoid those big vague predictions which are the root of all evil. If there's no T-shirt size for 3 months, then you have no choice but to actually break your estimate down to smaller chunks. This, in turns, forces you to invest just a bit more time into planning ahead than you might have otherwise. Suddenly you're reminded of holidays and hiring efforts, and integration, and setup time... This, of course, is tied to the first rule of project underestimation: it's not the estimates that are wrong, it's the plan that's incomplete.
If you allow yourself overly specific large estimates you also introduce a mental block: you've checked the box. It's "done". You wrote down "4 months" as your estimate for that distant milestone and now you don't have to look at it again until you reach that task. How convenient. If, on the other hand, you only allow yourself to provide smaller estimates, that milestone is now sitting there taunting you, begging to be further elaborated. You may be comfortable with a large estimate that's not based on reality, but if the aggregate estimate is small because you haven't yet taken the time to drill down even a bit to day-scale, well... that's just unacceptable.

Third, it's harder to argue with TSE. Which is another way of saying it's easier to accept a TSE. When your manager sees you've created a well thought out plan in advance that tries to capture all those details that normal intuition misses, he's not going to haggle with you over your that one-week estimate for integration time ("one week? no no... it's 4 days at most!"). That's just not going to matter. Everybody knows we're not that good at estimating in that scale, anyway, so as long as an estimate isn't egregiously wrong people just move on. The discussion is suddenly focused on the content of your work plan, instead of the price tag attached to each task. Now the challenge is "who can think of more shit that can go wrong, that you forgot to include" instead of "who thinks this feature can be developed in less time".

I believe TSE needs to be the default method for estimating projects, as long as they're restricted to small sizes. Gigantt uses a variation of TSE. Our estimates aren't actually S/M/L/XL. Here's what estimates currently look like.

one week task estimate

The largest option is one week. Estimating a task is a one-click operation. This really reduces the friction of estimating (something people just don't like doing). It's always going to be the preferred, easiest way of estimating in Gigantt. In future versions we'll also add 0-duration estimates, for checklist type tasks (e.g. milestones). We may even add custom estimates (e.g. "4 months"), because we realize not everybody shares our above views on how to properly estimate projects and alternative project management solutions do offer this feature ubiquitously. But even if we do it's certainly going to be the 2nd choice, and we hope most users won't take advantage of this feature at all.

Ants, Popcorn & Sex – An Introduction To Resource Leveling Algorithms

2011-05-13T13:03:00.000-07:00

What would you do if you were asked to plan the construction of a building? Construction projects are typically big, involving many people and resources. They're also time-sensitive - you have exactly one week to build each floor, and the material for the next one needs to arrive just in time. Cement won't wait.

Since the 50's various methodologies have been developed to tackle the issue of creating a work-plan that result in a smooth-running project, with as few costly delays as possible and without wasting precious resources. Most notable in the construction industry is the Critical Path method. But while CPM may help you create a logically coherent plan that finishes on time, it doesn't really guarantee you that your plan is optimal in any way. What if the whole thing could be finished two months earlier? What if it could cost a lot less money simply by better utilizing the same resources? These are big projects with big money that needs to be spent correctly.

This brings us to the concept of resource leveling. It's easiest to describe what resource leveling is by giving examples of projects running without it. For example:

Workers are standing around idly because it's not their turn to use some machine.
Lots of people are hired at the beginning of the project and then need to be fired when they're not needed.

It's all about making the best use of limited resources. Ideally, you'd want to hire a fixed number of people and employ them fully for the entire duration of the project. When that's the case your project is optimally planned for the amount of resources it may expend.

To better illustrate what resource leveling “looks like” resource histograms are often used. It's just a graph with two axes: time and resources. The horizontal axis is usually work days and the vertical axis is the amount of resources used (e.g. man hours).

Here's a terrible one where it's easy to see that resources aren't used evenly throughout the project.

Resource leveling is all about getting that histogram to have a rectangular shape. If all of your workers are constantly employed then there's not much to improve - you have a perfectly leveled plan.

It is thus the process of moving tasks around, while still maintaining their logical order of dependence, in a way that maximizes the use of your available resources. Resource leveling algorithms differ mainly in the way in which you choose which task to move where.

Turns out it's a hard problem. NP-hard, to be exact. In other words, you can't simply try all feasible task arrangements until you find the optimal one. Unless of course you project is tiny, trying to exhaust every possible solution to the problem generally requires an exponential running time, and your deadline is probably before the next ice-age, so no luck there.

The problem is known as the resource constrained scheduling problem (RCSP). In a way it is a generalization of the traveling salesman problem (TSP). There are tons of very clever algorithms that try to solve these problems by approximating the optimal solution. They differ in their running time and how close they get to an optimal solution. Some of them are pretty neat. Let's review them.

Heuristic Algorithms

This family of algorithms tries to use rules of thumb to make decisions. Remember, the decision a RCSP algorithm has to make is which job to shift in time in order to evenly distribute resources. Not every job can be moved. Some have to happen at a very specific time and have many successive jobs depending on their completion. But there's always some degree of freedom (or float) in the plan, and that's the space in which these algorithm mostly operate.

An example of a heuristic is the following rule: choose the job with the most float from all the jobs in the last sequence step of the plan (i.e. it's final stages), and move it to a location where it has the biggest positive impact on the plan's “levelness”. Do this repeatedly, constantly measuring how leveled the resource histogram is at every step, until you can improve no more.

It's a relatively simple heuristic - too simple, really. Think about it; why should it find the optimal solution? It scans the work plan from end to beginning, greedily shifting jobs as much as it can. Why start at the end? Why not shift the smallest job instead of the one with the most float? It might very well make some unfortunate early decisions that would prevent it from reaching the optimal solution.

Most heuristic algorithms are considerably cleverer than the one above, but they've long been considered insufficient since it's not hard to find negative examples where they produce really poor results.

Metaheuristic Algorithms

Instead of following a rule of thumb when searching the solution space, metaheuristics often try to take cues from various natural processes in trying to figure out their search strategy. How do ants “know” the shortest path from their colony to food? How do organisms “know” how to adapt to their environment? Let's see how the answers to these questions can reveal interesting solutions to RCSP.

Genetic Algorithms

Which job shall we shift next and where do we shift it to? Deciding on this question over and over forms a path through the solution space. Our goal is to find the global optima – the place in which the histogram is rectangular (i.e. has a minimal moment, or in other words the least amount of fluctuations in resources). If we measure how leveled a plan is by some function F (for Fluctuations), we can describe our effort as trying to find the lowest point in the solution space, where F reaches a global minimum. The solution space usually has many dimensions, but for the sake of illustration let's think of it as a 3D terrain. Your goal is to reach the deepest valley, but you can't look ahead more than one step. How do you decide which way to go? Where do you even start?

Instead of trying to solve the problem directly (as the heuristic algorithm above) metaheuristic algorithms are good at taking an existing solution and improving it iteratively. Genetic algorithms belong to this family. They start out by creating a few solutions somewhat at random. Each solution is encoded as a “DNA” sequence. For example, if the path a solution takes is “left, right, straight, straight” then its DNA can be encoded as “LRSS”. Each solution's fitness (how well it levels the histogram) is measured and the best ones are mated with each other to produce offsprings that share half of each parent's DNA at random. Then the process is repeated with the next generation. By adding randomness in the form of mutations we can prevent the algorithm from fixating on a sub-optimal path for too long. Mutations drive the algorithm to explore new paths, and getting rid of the unfit drives the algorithm to improve the promising paths.

A major challenge of such metaheuristics is, indeed, not getting stuck in local optima. A cool way to overcome this challenge is called simulated annealing.

Simulated Annealing

Imagine we're trying to find the deepest valley in the terrain pictured above by scattering a few popcorn kernels from above and letting them fall into the valleys. You want at least one of these kernels to reach the deepest valley, but how do you prevent them from getting stuck in a local valley? You turn on the “temperature” of the terrain until they start to pop and jump around slightly, possibly jumping right out of the local valley they might be in. You then turn the temperature back down and let them continue falling. This is similar to how simulated annealing works. Just like a metallurgist heats up a metal and cools it over and over to make it stronger, the simulated annealing approach to RCSP allows the algorithm to explore the solution space by converging on promising paths (cold) but also jumping around to explore nearby paths every once in a while (hot).

Ant Colony Optimization

Ants are smarter than popcorn. Collectively, that is. Individually, not so much. Let's see how ants would find the deepest valley. Ants seek food pretty much at random, at first. They don't have a fantastic sense of smell like dogs, or amazing vision. But once they find food they somehow converge pretty quickly onto the shortest path from their colony to it. It doesn't take them long to form an orderly single file that shoots directly to the food and back. They do this by secreting pheromones.

Each ant secrets a pheromone that causes other ants to want follow it. The more pheromone an ant picks up, the more likely it is to go in its direction. If an ant finds food and travels back and forth on the same path, it secrets more and more pheromone along this path, making it more and more appealing to other ants. And the more ants follow the path it becomes even stronger. It's a feedback loop that makes the ants converge on a path to food. But that's only part of the story. The pheromone also evaporates over time. So what happens if two ants find two separate paths to the same food, but one is longer than the other? The longer path takes more time to travel and as a result the pheromone has more time to evaporate, making it ultimately less attractive to the ants. So ants don't just find food and “tell” each other about it, they also iteratively find the best route to the food by choosing the one with the most pheromone on it.

We can do the same for the RCSP. Start out with a few feasible work plan arrangements and let simulated ants search for improvements. When an ant chooses a modification to the plan that results in a more rectangular histogram (an improvement) we deposit pheromones along the path to that solution. The bigger the improvement, the more pheromone we deposit. Pheromones here are just the probability of an ant following the same path. Ants will still wander off a bit, trying to explore nearby paths, but as the scent becomes stronger they will converge on a good solution. Pheromone evaporation will make sure they choose the shortest path.

There are many more approaches to solving such global optimization problems: artificial neural-networks, packing algorithms, monkey searches, tabu search, bee colony optimization (like ants, but with dancing instead of secreting).

What's neat about all these algorithms, aside from their awesome names, is that they don't require a real understanding of the particular problem at hand. They don't rely on intuition in deciding how to reschedule jobs. They just know how to improve an existing solution.

Collaboration in Gigantt

2011-05-10T15:37:00.000-07:00

We're in the final testing stages of the first version of Gigantt that supports real-time collaboration. You can see what it's going to be like in our new preview video.

turn on your speakers for full enjoyment. :)

Gigantt takes a novel approach to collaboration. We want to allow multiple users editing the same plan at the same time - seeing each other's changes as they are made (like Google Docs, Wave) - but we don't want people stepping on each other's toes. Our solution is called a freeze period. Basically anything you touch while editing a plan in Gigantt gets frozen for everybody else for 60 seconds. So each user can safely edit his own area of the organization's big work plan.

This approach has the advantage of making it visibly clear when someone else is editing the plan with you, so you can avoid conflicts instead of having to resolve them. We think this is a better form of collaboration than what most other collaborative systems offer, where if two people are editing the same document one of them will be notified of a conflict once he tries to save his changes (e.g. Wikipedia). We believe true collaboration is not racing to save your changes before someone else does, but rather being aware of who's editing alongside you right now and being able to give each other just enough time to edit in peace.

Our apologies, again, for taking so long working on this release. We want to get it right. Many people have signed up for an invite to the private beta program - more than we can handle at this point. But once this collaboration release is finished we're immediately going to start working on the registration/invitation system (now it's all manual) so we can let more people in. Thanks for being patient.