Archive for the 'Uncategorized' Category

Vernor Vinge’s Technology Predictions in Rainbows End

Wednesday, July 19th, 2006

Vernor Vinge is one of my favorite sci-fi authors. I just read his new book, Rainbows End, and I highly recommend it. It’s set in the near term future (within 20 years), and it has a bunch of technological and social predictions I want to list here since I can’t find them on the Internet (Vinge has a 50 min podcast available which discusses some of them). These aren’t plot spoilers, but they are technology spoilers, so don’t read this if you plan on reading the book:

  • Affiliances - These are some kind of part-time work / large-scale special purpose corporations. I think the great idea here is that with the right software and network infrastructure, it should be possible to break down problems into arbitrarily small sub-problems which can be outsourced to other people anyplace in the world.
  • Belief Circles - This is directed online communities on steroids. This is when online communities which have a common belief system (say fans of Harry Potter, Trekkies, etc.) spend so much time together online that they are able to accomplish things in the real world too.
  • SHE (Secure Hardware Environment) - Following the trends of many modern governments to control encryption and other advanced or threatening technologies, the ultimate dream of government control freaks is that all computing hardware must be regulated by the government. And this government regulation requires that the lowest level computing infrastructure gives back door access to the government to everything that takes place in computers.
  • Localizers - Imagine very cheap wireless sensing machines the size of a grain of sand (something like this but smaller). And if they’re really cheap, and they’re scattered in every square meter around the country, then you’ve got ubiquitous high-bandwidth networking to everybody everywhere. But bye-bye privacy.
  • Contact lens overlays - The idea is that you can change what you see through your eyes with your contact lens (but in his podcast he says he might change it to retinal implants). Instead of painting your house, just have everyone in your family use the same color overlay!
  • SM (Silent Messaging) - People can send instant messages to others without talking or typing — I think the idea is that someone growing up using advanced computer interfaces would be able to interact with their computer interfaces without explicit or at least viewable muscle movements. Wouldn’t this just be technological telepathy?
  • Large Teams Acting as One Giant Brain - What if you had high bandwidth and productive communication between all of your team members, and the team members were experts in a large range of areas, wouldn’t the whole team acting together seem like one god-like intelligence?
  • Friends of Privacy - This is some group of unknown people on the Internet who publish subtle and not-so-subtle lies to make it difficult to trust the information you read about people online. In other words, anonymously-published large-scale disinformation.
  • YGBM (You Gotta Believe Me) - This is technology that let’s you manipulate people’s minds through broadcast media. I think it’s probably possible to control people, look at cult leaders for an example.
  • Ubiquitous Support - Imagine a real-time Google Answers. Imagine if you’re a programmer and you’ve just spent 2 days stuck on a problem, what if you could, immediately and in real-time, pay to get one hour of help from some expert programmer somewhere in the world?

Hello WordPress

Friday, April 21st, 2006

We just moved our weblogs from PyBlosxom to WordPress. I’ll subsequently explain how we did it.

Top Five Problems with Fixed Price Contracting

Wednesday, March 8th, 2006

I’ve spent a number of years doing IT consulting, and I’ve been on both sides of fixed price bidding and contracts.
Below I put together five problems I’ve seen, and I describe anecdotes that really happened from the point of view of the
consulting / solution provider (I’m just hiding identifying details).
Please note that these problems are more likely to occur the larger the project is (at least $100,000).
And before you protest: some projects don’t have these problems, but most do!

Everything is Grey

No matter how detailed and specific your contract and agreed requirements are, there are always multiple ways
of interpreting human language. Unless the requirements can be evaluated by a computer, there’s going to be
a human deciding whether the requirements have been met.

Once I was a developer on a project to translate a large code base from VAX Pascal to DEC Unix C++.
My boss, not a standard IT saleman, negotiated the contract, and he was a real stickler for details.
He actually got the client (a defense contractor) to agree that we were finished development
once a set of agreed-upon unit tests passed. I think that’s pretty impressive — there could have been a million
other details needing to be translated but not covered in the unit tests (since the unit tests had to be
agreed to in advance, there was not enough time for either side to confirm that they covered sufficient ground).

Above, I was just being cheeky and showing the exception that proves the rule — almost all other projects just
have Word docs and rough prototypes as their specs.

There’s Always Contention

It’s just human nature — whenever you have people with different motivations working together, you’re
bound to get contention.

Once I was working as the technical lead on a J2EE project, and after it went live, there were performance problems.
The app ran fine under a light load,
but once a certain threshold was reached (less than 10 people!), performance dropped off a cliff. The whole team
was working really hard to figure out the problem, and I was getting pressure to go to the client’s site
to make them feel better (they were freaking out since the system was essentially worthless when it ground to a halt).
I didn’t want to fly to the client, especially since I knew that I could not figure out the solution in an airplane
or in a face-to-face meeting with an angry client trying to tell them everything was OK. We figured out the problem
(it turned out a former coworker did not know that Oracle does not automatically
create indices for you ;-) . By that time my boss’s boss was sitting on the airplane runway to fly up to the client.
Well, at least I avoided the client’s insistence to visit!

There’s Always Change

For any project that takes more than a week to complete, there will be changes, either to the specs, or to the
members of the team. Maybe the client or solution provider’s company will be bought. There can be
changes to the project’s standing in the company (maybe more important, maybe cancelled), or the project team can have greater insights while
trying to implement the project. Or the client just forgets some details. Any way you slice it, you’re going
to get change.

Once I was the technical lead on a smallish project (around 3 months with 4 people) for a pharmaceutical company,
and it was the first project by my department, so my management wanted to make sure it went well. Halfway through implementation,
the client started asking questions. How do I add new users? (Uh oh, no one spec’ed out an admin section.)
Why aren’t you following our manufacturing calendar? (Uh, no one told me about it, too bad we had tons of date-related calculations
that needed to be redone.) Where is such-and-such data? (I didn’t even know, but it turned out we needed to setup
and use a daily feed from another system.) Why isn’t your webapp following our password policies? (That’s how I learned
that we needed to integrate authentication with their Windows domain.)

Salespeople Can’t Say No

As soon as the people making the sale are different from the people doing the work, you’ve got a problem.
And the problem is that these two sets of people have different motivations. Salespeople really want
to get their commission, but they only get paid if the client is happy enough to pay the bills.
Saying no to client requests runs the risk that the client won’t pay, or will underpay, and that would hit
the salespeople’s commission. On the other hand, the actual project team
just wants to put in the minimal work necessary that they don’t get in trouble (the exception is if they get paid
for doing overtime).

Once I was stuck on a long drawn-out project, which was running late and been rescoped a couple times already.
We were doing a “final” review of the technical specs, before we were to finish implementation. In this meeting
were several representatives from the client, our developers, and representatives for upper management
from my company. At this point in the project, my management was worried that the client would bail out and not
pay. So as we went through the specs, the client was free to add any features they wanted. And did they add them!
I tried to protest, since we were supposed to be clarifying requirements and not adding them, but without any support
from my side (here my management was acting like salespeople) there was nothing I could do.

At the End, Nobody Gets What They Originally Expected

Due to all the changes that take place as a project progresses, the client loses some features they wanted, but hopefully gets
some features they needed. And the project team has to put in some overtime to get things done by deadline.

Once I was a developer on a small intranet project for a pharmaceutical, and the project team was working directly
with the business folks since the project was being run in-house. It was kind of amusing to me that the business folks
had never worked on an IT project before. Boy, did they get a surprise! They thought their project was going to be
simple and easy to implement — it was just to track salespeople’s territories. They didn’t expect that:

  • The project would be considered “validated”, thus requiring extra paperwork and slowing things down.
  • IT folks won’t do anything unless it’s been agreed to in the tiniest detail. And when the detail is not there, then you just go in feedback circles making minor tweaks.
  • Cross-system integration is painful and always takes longer than you expected — even if you already took that into account!
  • The poor business folk had to do testing because they hadn’t budgeted for external QA. How annoying!

Conclusion

Even though some things above might sound negative, all the projects completed successfully!

SVG vs. Canvas: Tastes Great, or Less Filling?

Sunday, February 12th, 2006

Now that there are two up-and-coming web graphics technologies (SVG and canvas), I thought I’d research them,
see what’s the difference between them, and see if they’re usable now.

Canvas Tag

The canvas tag got a lot of attention a while back when Apple announced they were adding it to their Safari browser,
and that they were using it to implement some of their Dashboard widgets.
What is it? Basically, the canvas tag is an “immediate mode” graphics technology — you start with an empty image jammed into your browser
page, and it’s your job to color all the pixels using javascript. It’s
going to be a “standard” by the WHATWG.

Below is a summary of current browser support for the canvas tag:

  • Firefox: 1.5 is first major Firefox release with it built-in
  • Safari: version 2 has it
  • Opera: 9 preview has it, will be in next major release
  • IE: of course it doesn’t support it. someone tried writing a small javascript emulator
    but that was just an experiment and not a real project

Here are some cool demos using the canvas tag:

SVG

SVG, or Scalable Vector Graphics, was made a standard by the W3C years ago (v1.0 in 2001 and v1.1 in 2003).
For a while it looked like just another W3C party where no one showed up.
What is it? It’s a “retained mode” graphics technology where you declare your graphical model as a tree of objects,
and the browser takes care of rendering it for you. Since the browser has your model, it can do lots of things for you like detect mouse clicks on objects and
rescale your picture to an arbitrary resolution.

Below is a summary of current browser support for SVG:

Here are some cool demos using SVG:

Conclusions

I took a graphics class in college a decade and a half ago, and the concepts remain exactly the same.
In general, SVG and canvas are complimentary, rather than competing, technologies. Anything you can do in one,
you can do in the other, but each one is optimized for certain situations.

Below, I put together a table summarizing the tradeoffs.

Feature SVG Canvas
Draw geometric shapes Easy: use SVG tags Easy: use API
Manipulate pictures Hard: Need to use poorly- or un-implemented image/feImage tags Easy: use API
Object Model Easy: You declare model, browser renders it. Model is part of DOM. Hard: No model. You can maintain your own Javascript model (fun!).
User interaction Easy: Event model is integrated Hard: None out of the box - you have to implement all event handling infrastructure, like tracking coordinates of objects in model.
Resizing Easy: that’s the S in Scalable Medium: You write the resizing code

You should know which technology to use based on your project and requirements.
If you’re just rendering some graphics, and you have no need for user interactivity, then the canvas tag is more appropriate.
If you want to have user interactivity, or if you have some other need for a model or user interaction, then SVG is more appropriate.

Ignoring the above trade-offs, if you want a technology that runs in all major browsers right now, then you have to go with SVG.
And that’s probably good, because my completely unscientific guess is that SVG is more appropriate for most (but not all!) applications.

Bottom line: SVG tastes great, but canvas is less filling.

P.S. Just for fun, I generated a GANTT chart using SVG and canvas to show how to write simple stuff
(if you have IE, don’t even try that link. :-) . I learned that for basic stuff, the APIs are quite similar. I also learned that
embedding SVG in HTML is a pain in the butt, which is why I put it in a separate page here.

Introduction to Geographically Distributed Development (GDD)

Monday, January 16th, 2006

One niche that we’re targetting for our ProjectPipe product is
geographically distributed software development teams. Before the rise of the Internet (in the 1980’s and early 1990’s),
only the largest companies (i.e., Fortune 100) could afford to setup development in multiple geographic locations.
I think the original purpose was to have multiple teams working around the clock in different timezones
to increase the speed of development on projects. Products like
Rational’s ClearCase MultiSite
were used which supports multi-master replication — really cool technology, but you need a six figure budget
just for the initial setup, and at least one full-time admin for support and maintenance.

Nowadays, things have changed with the worldwide Internet leveling the cost of global communications.
Many products have been designed to work over the Internet, and they don’t crap out if your connection is slow.
For instance, you can use CVS and its descendant Subversion over a fast LAN or slow Internet connection.
As a counterpoint, ClearCase was designed to work
over LANs, and if you try to have its standard client talk to a server over the Internet on a VPN, you’ll see terrible performance and frequent
failures because ClearCase has very chatty client-server communcation — to be fair, they have a more recently introduced web-based client
which is missing some features but at least works over the Internet.

I could analyze all the tools you need to run geographically distributed development (GDD), but they all have the same need:
to be available anytime from anywhere in the world. Most client-server and even some web apps don’t fit this criteria.
IBM has a nice article about using IBM’s products
to do GDD
. But I’m not worried about IBM as a competitor. It’s true, they have googol (not google :-)
more software than we do, but their products are consultingware
– where it looks like shrink-wrap software, but really you need to hire experienced consultants to install and customize
it to do anything, let alone what you want.

What is Project Management?

Friday, January 6th, 2006

While writing marketing literature, I was trying to figure out what ProjectPipe’s product category is. So far I’ve been
saying that we do “project management thru-the-web”. But it’s a little confusing to me because we integrate with
MS Project, which claims to be a “project management program”. If you have MS Project, why would you need us?
Both do project management. Is ProjectPipe just MS Project on the web?

The simple answer is no, we are not MS Project on the web. We are not interested in rendering
Gantt charts on the web. Some companies are doing that
– good luck to ‘em! (Though if SVG ever takes off then maybe I’d do it. :-)
ProjectPipe has a very different focus than MS Project — both products have mutually exclusive and complementary
features. ProjectPipe tries to cover all the major areas of project management defined
in PMBOK (Project Management Body of Knowledge).
However, MS Project just covers task and resource scheduling. Admittedly, that covers a lot of ground — budget
over time, resource levelling, etc. But it doesn’t cover: issue tracking, source control/asset management,
risk management, requirement tracking, etc.

It would be nice if there was another phrase besides “project management”, something like “project lifecycle management”
but I think we’re stuck with this ambiguous phrase.

Ian Landsman’s 4 Rules for the Practical Entrepreneur

Friday, December 30th, 2005

Ian Landsman just wrote a great little piece outlining

4 criteria to evaluate a new product against

. I’ll take the bait and evaluate our new product in this context.

1. Fragmented Market

Pass - I’d say that the project management thru-the-web market is highly fragmented without one clear dominant vendor yet.
The desktop project management market is dominated by Microsoft, but we’re not competing with them
– rather, we complement them by integrating with them.

2. Business Before Consumer

Pass - we’re only targeting business. I can’t even imagine what a consumer-oriented multi-person project is.

3. Clear and Simple Revenue Model

Pass - we have a really simple table summarizing
our prices and product options.

4. Dog Food

Pass - we’ve been using our own stuff for a while now. And it really is great advice
– when we initially cut over to using our system, we found a bunch of bugs and missing features.

In summary, we pass all 4 rules!

Why Python?

Thursday, December 22nd, 2005

Here’s a question I get sometimes: why did we use Python? I had been programming in J2EE/Java for six years
before ProjectPipe. I had used most of the major technology areas in J2EE: ejb, servlet, jsp, jms, etc. I had
lead several successful projects that mostly used BEA’s WebLogic app server (for a while it was the best J2EE app server),
though I also used the JBoss/Tomcat combination as well (mostly during development because it was faster to reboot).

We’re not the only people who have left J2EE for hopefully greener pastures. Bruce Eckel just wrote
an article about people leaving Java for Ruby.
I left Java for Python. I left for two reasons: 1) my buddy Mike bugged me to look into Python and 2) once
I got over the white space/indentation Python issue, I found my productivity is higher. It’s difficult to compare
your productivity when using two different technologies, because once you solve a problem using one technology,
you’ve learned some things and it’s easier to solve the same problem in a different technology. Anyway, the only
concrete difference I can offer is that it used to take about a minute to boot up a J2EE app server, but I can boot up
my Python app server in 2 seconds. If you consider that during development you might reboot a hundred times in a day
(you usually don’t have to reboot in either technology if you just change a web page), then you can see that you might
lose 6000 sec (100 x 60 sec) or 100 minutes using J2EE vs. 200 sec (100 x 2 sec) using Python. Of course, when your
app server is rebooting you might look over code, but on the other hand it’s very distracting to wait an entire minute
before you can test changes you just made — you’re just as likely to keep surfing the web an extra ten minutes while
waiting for your app server to finish booting up. And since J2EE is so damn complicated, it’s tough to write unit tests
– I’ve done it occasionally in J2EE, but you usually have to either test outside of J2EE or go to the trouble of
setting up and using the Cactus testing framework. If you write
tests using Cactus, you’re still stuck with your app server boot time.

The Python community has a number of database and web frameworks available, but Mike and I chose
Twisted for our networking and Nevow
for our web framework. We rolled our own database support (written on top of Twisted). Mike was the
instigator to use Twisted — it took a while to convince stubborn me to use it, but after looking around, I grew
comfortable because the guys developing it are really smart, and their arguments on the simplicity and scalability
of their async approach sold me.

I would say that the only major thing I miss from Java is the boost in performance you get with Java’s excellent
JIT (Just In Time) compilers that come with the JVM. A while ago in an old weblog of mine,
I made some simple performance measurements
and found that Java with JIT is something like an order of magnitude faster than Python. Though I’m keeping my
eye out on the PyPy project which is working on JIT technologies
for Python (which is especially difficult because of the dynamic nature of the language).

Hello World

Thursday, December 22nd, 2005

One of my favorite SpongeBob episodes is Procrastination (sorry just a mediocre link),
where SpongeBob has writer’s block. He stays up all night putting off writing a short essay for Mrs. Puff, with the pressure building
the more he procrastinates, even going so far as to have Dali-esque nightmare of sleeping past his deadline.
(SPOILER: Yes he finishes his essay on time, but Mrs. Puff had cancelled the essay and didn’t tell SpongeBob.)
I’ll be honest and say I feel the same way trying to write my first blog entry. Taking the plunge anyway…

I promise you’ll get:

  1. Fresh content every working day from me or Mike.
  2. A little humor in all my posts.
  3. Something educational in all my posts.

Mike and I have developed a really easy to use hosted project management application.
We’re going to open it to the public real soon now — the private beta is just about over. We got some good feedback (thanks people!),
fixed a bunch of bugs and kept adding features.

Yes, the project management application space is crowded. However, crowded does not necessarily mean all niches have been filled.
You have the low end covered by such sites as Basecamp, which aim for short and small
projects such as web design. If you have a MS project plan with a thousand tasks, they’re not going to be helpful to you. And on the
high end, you have such “enterprise solutions” as Project.Net and eProject.
And when they say enterprise, they mean: no price quotes online (you have to negotiate, where the bigger the company the bigger the discount),
“on demand” means you wait for them to get back to you, and the feature set is described in hazy marketing literature.
But please understand, each company I just described has their own niche where their customers like how they operate.

Our product is a bit unique, we think that we have a good blend of the low-end friendliness and ease-of-use that people want, and the high-end
functionality that people need. We tried to design our application so that little or no training is needed to use it. We have two killer pieces
of functionality that I’ll explain more in a later post:

  1. Two way integration with MS Office (including MS Project).
  2. Easy-to-use traceability.

Usecase of Joining ProjectPipe - Jim Logs In

Thursday, December 22nd, 2005

Jim summizes the lousy in-house tool situation with his boss, and his boss agrees that it’s a shame.
When Jim asks if the company could pay for a hosted provider, his boss just
chuckles. Jim’s boss tells him that the project’s budget has already been set for the next three months, and
the time to get a purchase through accounting takes ages, but
if Jim personally pays for it that he could be reimbursed later from another budget area.
Having been burned in the past at other companies with unreimbursed expesnses, Jim sends a follow-up email to his boss
summarizing their conversation and cc’ing the business sponsor. The business sponsor sends Jim a private follow-up
email thanking him for taking initiative and saying he’s really looking forward to having a shared system so that
he and his direct reports can see how development is going.
Stated that way, it gives Jim the shivers, but he’s happy he got some brownie points.

So Jim ponies up for 1 month with ProjectPipe on his personal credit card.
He likes the fact that his user id is his email address - one less thing he has to remember.
He gets the login email in less than a minute, and immediately logs in.
The first thing he does is go to the team tab and invite his QA and developer guy. All he has to do is enter
their name, email address and role, and they’re automatically sent emails telling them how to login.

As soon as the team receives the invitation emails, they jump to work.
The developer imports the current cut of source code into the project’s Subversion repository, he wants
to play with it for a little while before moving the offshore guys to it.
Meanwhile, the QA guy imports the bugs from the most recent spreadsheet into the web app.
Since there are only a handful of bugs at the moment, he’ll just manually copy + paste them into the app,
but if there were a lot he could have used the small ProjectPipe client program to upload the data from
a spreadsheet (editor’s note: assuming Christian finishes that functionality).

While his team is busy adding data to their project, Jim installs the client program because he wants to upload
his MS Project plan into the web app. He probably would not have shared the project plan with the team
(he gets tired of developers nitpicking task timeline details), but since the business sponsor had talked
about it, he figures it’s better to be open and critized than quiet and fired later. Actually, Jim gets a little
happy (not too happy, he *is* a PM after all) thinking how he can CYA by saying that the entire project
plan and its status was always available to everyone on the team.

Jim reads up on how ProjectPipe integrates with MS Project, and is happy.
He wants to keep his .MPP file safe and local
and doesn’t want any program messing with it. He remembers the time when a BA took his 5,000 task project,
and ran Resource Leveling on it but didn’t tell Jim until he asked why the project had moved out several months
past deadline. Anyway, the ProjectPipe client is totally unobtrusive, after it asks for his email address,
password and project name, it just sits quietly in his taskbar. Its interface is through the web
(Jim wonders how they did that, but doesn’t much care that under the hood it’s using the XMPP/Jabber protocol,
as long as it works), so to import his project all
he does is go to the project tab in the website, click “Upload project to server”, select his file and click Upload.

To be continued…