Migration to Ubuntu

We have been running Windows XP Professional in the office, until not long ago. Things were generally working in Windows, and most of the time there were no complaints, but I have decided it was time to leave the Windows world, and what better timing than to do it with Windows Genuine Advantage is spreading like spyware, running in the background, and god knows what it could prompt the local BSA representative and his secretary to do to us poor fellas!

My own personal box had hardware problems, so I took it to the shop where the power supply was replaced, and the ATI Radeon was replaced with the nVidia 7300GS card. I came back to the office only to discover the driver of the nVidia card can NOT be installed! no matter what I tried, I got an error in the final stage of the installation, stating that the driver returned an invalid error code. I tried mailing the support staff that produced the card, a process which took 2 days to produce a result, and in the end I got no better answers than I have already found myself on Google. So that was that, I decided to drop Windows once and for all!

So it started with our server, which we installed with Debian Sarge, and that is running a “test” suite of our product, and is also serving as our file repository.

It then continued with the dev stations, which we installed with Ubuntu Dapper 6.06, and I must say I am impressed with how easy things went! It just works out of the box. I wanted to take the time and list the things that really surprised or amazed me with this process:

  • We are using Gnome + Compiz + XGL, the desktop is usable and looks AMAZING. I never thought I would see a desktop that looks and works even better than my dream system; MacOS X! — It’s smooth, it’s fast, it’s beautiful, and whoever walks into my office and sees me working, is absolutely amazed and leaves my office heart broken.
  • Thanks to “Automatix” we can play MP3 files, view videos, flash, etc. even quicktime embedded within web pages (great for viewing the movie trailers on apple.com). It even installed Beagle, which mimics “Sherlock” on MacOS X.
  • Applications, applications! We are using Firefox, Thunderbird and Eclipse. Needless to say, they work great, at least as good as their Windows counterparts, so not much fanfare there. It just works, we love it.
  • LAMP – Our product uses the LAMP platform, so it was a lot of fun installing one on our local boxes, so we can have a local debug version which we can play with, without having to go through the release cycle in order to see changes on the test suite.
  • Karma – We feel great, as if cured from some rare disease. The demon that is Microsoft no longer posesses our establishment, and I must say it feels amazing! No more DLL conflicts, no more blue screens of death, no more USB or Bluetooth issues, no more complicated driver installations – everything just works out of the box!
  • Office? Open! Thanks to OpenOffice we are free of the need to run Microsoft Office. Sure, I am used to Microsoft Office, after using it for YEARS. I mean, i’m using MS Office for the last 12 years, It makes sense that there would be some resistance to moving away from it but I must say the OpenOffice team have done an amazing job and it really was not an issue to move to OO. There are small differences here and there, but I am getting used to those changes every day of using the OpenOffice suite.
  • Ekiga is our softphone now, and I was impressed again when it found my Logitech QuickCam 4000 Professional. Last time I tried this in Debian, I failed miserably, and only managed the lower resolution captures, which were not reliable even. No more! This time it just works out of the box, I am making calls with Ekiga using my Logitech USB Headset (also detected out of the box), and video conferences with the QuickCam 4000. What a pleasure!
  • Winamp? I love Winamp, and on linux the alternative is XMMS or Beep, but they are not really as good as Winamp. Thankfully there are great alternatives. I am now using Amarok, and it’s really amazing. It brings lyrics for the songs I hear, it automatically rates them for me, brings information about the artist, brings album images, etc!

Top 12 Rules of Thumb for Project Management

I found this inspiring and “so-true” post by fprog of slashdot. The reason I loved it is that it’s so painfuly true, and exactly the kind of list I would prepare for myself or for anyone else before a new project / customer. Read, Learn and pass on!

Top 12 – Rules of thumb for project management

  1. Triple the estimated time + 10%.
  2. Add 2 weeks to that amount for a complete code review.
  3. Any changes by the customer means “adding 2 weeks to the schedule”, even if it’s one line of code… why? because, it must pass documentation, Q.A., validation and be reviewed by the entire department, without accounting for “double bug”, bug induced by another bug and stuff like that or bugs that are in the core library and means retesting “everything”, “every module”, etc.
  4. Any changes must be approved, reviewed and means adding delay (normally a big NO-NO) and therefore, 99% of the case thoses changes are left for future phases or abandonned by the client when they realise the implication. If not, it’s your objective to discourage them or force them to reconsider by any means. =P
  5. Don’t give any feedback to the customer unless you must! If you do, downgrade any progress to minimum to reduce expectation and refrain the customer from adding new stuff to the TODO list.
  6. Which means, each phase must be clear, consise, humble, realistic, feasible, with lots of buffer time for fixes, reviews and testing. Exagerating how complicated it is to a customer is always a good idea, because in the end, everything that seems easy is actually very difficult.
  7. Do minimum documentation, UML to get started… They’ll get rewritten at least 30 times, before everyone in the group agrees after what 40 meetings?
  8. Once the phase somehow works and the thing is somehow settle, start documenting it, so you don’t forget. It’s actually a very good way to detect logical mistakes, misbehaviors, bad coupling, bad cohesion, missing corner cases, bad design choices, usability problems, etc.
  9. Best teamwork is small team of 3-5 senior people working toghether hand-in-hand, sometime helped by 1-2 junior, which can do much better than 120 junior who are completely clueless and never deliver on time…
  10. For big projects split things up in component and/or phases that a small team of 3-5 people can do, keeping in mind of the big picture so its scales up, but ignoring any meaningless future details that don’t matter “right now”.
  11. Rush the people to do it in “the simple 1/2 time delay”, keeping in pocket the “double time” remaining for any arising issue and reworking the core libraries, overhaulin the code, reviews, fixing bugs, etc. This means that if you are really late, you are actually late on your “buffer time”. If things goes well, then the project will be done before it’s expected, which will impress any client.
  12. Finally, but not the least, there’s no such thing as a bug, it’s just a “small improvement”, a “new feature”, “code overhaulin”, “mispelled requirement” or a “security enhancement”. It keeps customer smiling, it’s less depressing for everyone and overall keeps the mood up on everyone face with a laugh or two!
Furthermore, no ones want to hear that the code is “full of bugs”, but saying that a group of people are always “enhancing, overhauling and improving the code base” also means a bigger bonus! =)

And one more good one by chaboud:

I think that the most important thing to do when a project is on an insane schedule is realize that you aren’t super-human and pace yourself. If you don’t, and crunch hard nights or extra-long 50-hour sessions, you’ll spend the next few days with a fried brain and a complete inability to make use of your time.

If you’re normally a 9-5 guy, pull 10 hour days. If you’re normally longer, possibly consider working longer, but notice when you’ve started lagging because of fatigue.

Other things:

  • Take walks. Get out, get blood flowing, and rest your eyes. Don’t stop to talk to people on your walks, because you’ll smoke hours talking about nothing (like postings on slashdot).
  • If you’re angry, or burned out, take a day. You can spend entire weeks in a funk if you can’t get yourself out of it. It doesn’t help you, and it doesn’t help your team. If your boss can’t make sense of needing to pull away so you can be more effective, try and find another job.
  • Be reasonable about moving targets. There’s no benefit to throwing a fit when your boss changes dates/requirements on you, but let him/her know what it’s going to cost in time or other features. Be quick about this. Don’t stew about it and let the feature-spec gel before you’re quick to pull the “we have to cut…” card.
  • Big design up front: Don’t do something three times because you weren’t sure how you were going to do it in the first place.
  • Less design up front: Don’t overdesign something because you’re so hung up on not doing it twice. You might have to code it twice, or three times. Get dirty in the code long before you’ve started sweating details that don’t matter. If you’re solid, this stuff will just flow out naturally.
  • Learn to use copy and paste, along with other tricks to save yourself grunt-work time. It amazes me to no end how much time I see some programmers spend on writing code. On the same note, learn to type quickly. I’ve known some great programmers who were hunt-and-peck two-finger typists, and those are the same ones who generally pulled super all-nighters typing at 20 wpm.