max.lueb.be

According to the documentation the last changes were made in 2008, and the project is frozen pending a next generation application. As this was two years ago at this point, I’m not holding my breath. So that being said, here’s the rough plan of attack:

Phase 0: Do some exploratory surgery on the code, make a spec, come up with rough estimates, generally standard prep work best practices.

Phase 1: Straight port to language ‘X.’ (Language to be determined, the goal here is just make it work). Test the shit out of it. Release early, release often – first usable code ships replicating what already exists.

Phase 2: Refactor core architecture and design into something much more maintainable. Start building a community around it, pull in domain specific experts to help steer the project and help validate output.

Phase 3: Experiment with interface and modern concepts (Cloud, mobile, touch, GPU acceleration)

This will probably be a much more difficult project than I currently estimate, but will be an awesome exercise in taming legacy code as well. Next time, updates on Phase 0 and preproduction work!

In my last post I ranted about the current state of software used to do engineering work, which I consider to be somewhere in between awful and abysmal. Now let’s ask – why this is the case?

Often it’s because engineering software is written by… Engineers!

Is it all that surprising that a program meant to simplify or automate some aerospace engineering calculations, under closer inspection of the source – turns out to be total garbage? Someone wrote the program in question to make their life easier, and barely got it to work, given the one semester mandatory numerical methods class they probably slept through. Hence it shouldn’t be surprising that the original author was completely ignorant of algorithms, data structures or anything resembling modern software engineering practices. Even worse, there is a high probability the program is written in some barely readable dialect of Fortran.

This problem in quality seems coupled to the essence of the problem the software seeks to solve. Who else is going to want a program that automates aerodynamics analysis besides an aerospace engineer? Certainly not your average Joe Doubleclick on the internet! Engineering software is an extremely niche market, which would likely seem a more difficult one to monetize than something aimed at a wider audience. Developers certainly aren’t jumping at the chance to write programs of this nature.

It also doesn’t help that these types of apps are very difficult to write given the amount of domain specific knowledge they require. Without an expert in the given subject area to assist in the design of the program, it will be hard to get it correct and verify the output. How will a developer know that the program they just wrote to compute the distribution of force in a suspension bridge is actually correct if they personally know nothing about physics, statics or mechanical engineering? It goes without saying that  the potential consequences of mistakes here are astronomical. If a faulty bridge is constructed from designs created by a faulty program, or a wing section is designed incorrectly due to software producing bogus output – there is a potentially large monetary risk when the fabricated structure fails, and depending on the situation human lives could also be at risk.

Computer Scientists have been largely spared from this dilemma due to the fact they are extremely proficient at building their own tools. A modern compiler or operating system is easily as complicated as some of the earlier mentioned design scenarios, but the tools used to construct them are excellent. The GNU toolchain is a perfect example of this, extremely high quality tools that are open source and widely known in industry. It’s unfortunate that the other engineering disciplines  haven’t seen the same gains in a tools windfall the software industry has, because its obvious to see how it has transformed the field.

Building better tools is hard and unattractive, but definitely can usher in some dramatic change. Computers shouldn’t be a distraction in engineering work, they should be an enabler. As software engineers, how can we make these problems manageable? How can we help our colleagues in other fields escape from this quagmire of terrible software?

Engineering software is written by engineers and it shows.

I remember using software in a digital design class in 2004 that was written for Windows 3.1 and would crash if you used filenames more than 8 characters long.

A year later I took a circuits class that had a large amount of simulation coursework. Assignments were required to be completed using a proprietary, feature crippled program that was locked to prevent working with designs that had more than 50 components.

A final anecdote that comes to mind was a 400 level advanced digital design class I took in 2008 where your grade was dependent on simulating hardware on 200 MHz Sun workstations. The lab that had these machines was also only open certain hours of the day, so in order to have any chance of getting your work done you pretty much were running in there inbetween every class. (I hacked this situation by “volunteering” to be the lab supervisor for the room in question, which put me in charge of locking up for the night…)

Engineering school is hard enough as it is and it doesn’t help that all the software is awful, closed and tethered to platforms that are old enough to apply for a drivers license. How can we expect students to be researching and developing the next great things when the tools they have to work with are so fundamentally bad? With the leaps and bounds of progress made in the last 20 years of computer hardware and software, this situation has become totally unacceptable.

As a thought experiment, I’ve been asking myself the following questions:

What engineering software exists that is open source?

Can engineering code run in the cloud?

Can engineering design work be done on mobile devices?

This genre of software seems ripe for disruption! Innovation in engineering software, although possibly unglamorous (I doubt Techcrunch is going to get fired up about an open source digital design package) has the potential to make a big difference – I am definately excited to continue brainstorming and to see what I come up with!

Last October I became disenchanted with where my startup was heading, and especially with how it was being managed – and decided to see what else was out there. My options were to look for new tech work in the bay area, or to go to another one America’s other tech meccas: Seattle or New York City. Being originally from Chicago, and having visited several times – New York seemed like the ideal place to go, and a much needed contrast to the suburban wasteland of the South Bay. Throughout October I interviewed with several tech companies in the city, and was lucky enough to get three offers – two from startups and one that was THE offer you can’t refuse – a chance to work for Google.

I had decided to interview with Google after hearing that even if I didn’t make the cut – it was worth going through just for the experience of going through their gauntlet. The interview itself was a nightmare in itself which is a story best saved for another post (having nothing to do with Google and everything to do with colossal incompetence by American Airlines) but in the end I survived, and two weeks later had to make one of the more difficult decisions of my life: continue to work in the startup world, or go work for Google. In the end I decided that irregardless of pay (offers from startups were for higher base salaries) or perceived loss of freedom in going to work for a big company, it was a chance I couldn’t pass up.

Fast forward four months later – this was 100% the best decision possible. Working at Google is as good as it gets, for reasons that have nothing to do with free food (although thats a pretty great perk!) To start with – everyone here is good, like scary good, at what they do. There is just an atmosphere of excellence that is hard to find almost anywhere these days. People here seem to love what they do, and that makes a world of difference.

Something else that’s mindblowing is when you sit down for breakfast with your team one morning, and you find out the other guys at the table you’ve been chatting with: invented AWK… or headed up IBM Research… or invented lex… or coauthored K&R… Chances to interact with living legends like this on a daily basis just don’t exist elsewhere. Like it’s pretty amazing when you send out an email with a question on the most pythonic way to tackle a given problem, and you get a response from Guido van Rossum.

Aside from brushes with celebrity – Google is somewhere where you learn something new everyday, and an awesome place to grow as an engineer. You work with technology that doesn’t exist commercially and at scales that just don’t exist anywhere else.

If you get the chance to interview here, or are lucky enough to get an offer – take it. Google IS Google. Nobody else comes close. So go read Steve Yegge’s post on preparing for the interviews, and send in your resume. You won’t regret it!

In a recent post, I explained how to install the Thrift RPC framework on OS X 10.5. Another scenario that doesn’t install as advertised out of the box is building Thrift on Ubuntu server. Again, an issue with pkg.m4 is to blame – follow the steps below to get Thrift built on your Ubuntu system:

As in the previous guide start by getting the latest revision of the Thrift library, and extract the archive.

Install the necessary prerequisites, which is much easier than on OS X thanks to apt. Fire up a terminal, and use apt-get to pull everything. Substitute java5 with your favorite jdk, if you’re not a fan of the Sun implementation.

apt-get install libboost-dev libevent-dev build-essential
python-dev automake pkg-config libtool flex bison sun-java5-jdk

Now, for the pkg.m4 workaround!

cd [thrift root]
cp /usr/share/aclocal/pkg.m4 aclocal/

At this point, all that remains is to build Thrift. (If you want Ruby support, add ruby-dev to the apt-get list above, and get rid of the ruby flag below.)

./bootstrap.sh
./configure --with-ruby=no
make
sudo make install

Enjoy!