boora

Syndicate content

Final Presentation

Send by email
I create my final presentation in Google Docs, and there it shall stay.  Here's a link to it, it's open to anyone with the link, and you don't need a google account.

Deadlines

Send by email
During my four years in Catlin's FIRST robotics program, I learned a great many things. Most importantly, I learned how and how not to approach a deadline, and had some experience building the runway as the plane landed, so to speak. As deadlines approached, I would inevitably spend more and more of my life either wrapping the project up or rewriting large swaths of code. This last season, as my ultimate deadline approached, I spent the last week before the competition doing almost nothing but finishing the system. I spent about a hundred and twenty hours over seven days just developing, testing, and debugging. In an ideal world, I would've planned out my development schedule more closely, and avoided this grueling finishing lap, but sometimes last-minute panic is the motivation I need.

Unlike me, my co-workers at Boora knew what they were doing. They had the entire schedule planned out well in advance, and on my final day at Boora, we hit out 80% design deadline by about twenty minutes. While might seem like we cut it a little close, the previous week or two had been devoted to checking all of the two-dimensional sheets for errors and typos. Instead of madly scrambling as we neared the deadline, we methodically polished our work until our deadline. As a result, we finished confident in the quality of our drawings, rather than hoping we didn’t make a mistake.

Of course, the last week was far less fun than the previous few weeks, what with all the revising we ended up doing. Three whole days were devoted to nothing more than tagging every wall, door, and room in the building. The sheer weight of the tedium was intense, but after replaying a good deal of music, I finished. It made me appreciate the necessity for such large architecture firms, but it seems like better tools would remove the need for quite so many people. Many of the mundane tasks I’ve completed over the past four weeks could’ve been automated. Some of them I did end up scripting, one of the useful things I left behind. Now, they can run my printing script to save all the drawings to pdf files instead of individually printed each and every sheet. And yet...it seems like Revit could do this without external scripting and much more quickly than my solution accomplished. Similarly, maybe the Revit could be smarter about room and door tags, generating them automatically and allowing the architects to touch them up.

My experience at Boora, while valuable, convinced me not to explore architecture as a career option. Perhaps I could write architectural software, but the monotony is too great to give any real thought to pursuing this either in college or beyond. Still, it was interesting to see the internals of an architecture firm, and gain new respect for their patience and knowledge. They do need an acute design sense to pull off a good building, and patience to work with the limitations of the tools.

Prev    Next

The Demons of Bureaucracy

Send by email

This week I journeyed to the far ends of the earth, and met with the demons of bureaucracy.

 
Let me explain.  Michael Tingley, my oft-absent project mentor, promised I would get a chance to sit in on a meeting with clients.  In this case, the far ends of the earth was really just one end of the earth, commonly known as Corvallis.  The demons of bureaucracy were, of course, the clients.  A bureaucracy, for the unenlightened, is a form of administration so horrendously inflexible that it fails to accomplish anything useful.  For example, one part of this bureaucracy claimed that our trees along the fire lane needed to be trimmed to at least 12', to allow the fire trucks to pass by unperturbed.  Another part of the bureaucracy required that trees along the pathway not be more than 15' tall.  Try to envision a tree that fulfills those two criteria, and you'll see our problem.  Maybe you'll even burst out laughing--it's an absurd thought, but each branch of the bureaucracy sees it as not their problem, because rules are rules.  They try to offer reasonable compromises, such as "just don't plant any trees," but that merely creates an eyesore, and a huge contrast against the rest of the green-hued campus.
 
Work at Boora is nice because there is no bureaucracy.  Working some of Boora's clients, however, is less so.  This inflexibility to employ basic common sense undermines that which makes us human.  Our ability to recognize patterns, and subsequently break them, makes our minds powerful.  I'm not saying that one should break every rule in the rulebook just because one can, but that one should weigh the importance of the rule in the context of its usage, and either compromise or throw the rule out entirely.  Sure, you could be a rebel, break the law, and not wear a seatbelt, but that ignores the purpose of the law: safety.  Not only does wearing a seatbelt statistically increase your chances of survival in the event of a car crash, but it increases survivability for everyone in the car.  Yes, you can decide to jaywalk, but do so having verified you're not stepping out into the middle of traffic, especially when engrossed in whatever conversation you're having on your phone or head.
 
If everybody had enough common sense, would we need rules?  Absolutely.  Common sense is not a substitute for rules, and rules are no substitute for common sense.  They complement each other.  The purpose behind rules are not always apparent, especially in the case of a child, who has little experience with the presence of true danger in the world.  A bottle of bleach, for example, warns against consumption via the digestive system because not everybody knows what bleach is, and not everyone understands the inherent danger in a seemingly harmless bottle.  The demons of bureaucracy do not understand that rules and common sense are both necessary.  They use each exclusively, basing their decisions on rules or on common sense, but not a combination.  Because they are so short-sighted, and because their understanding is so nominal, they are the demons of bureaucracy.
 
Note: they weren't actually this bad, but some of the imposed regulations were pretty arbitrary.  I wrote this not against individuals or clients, but against bureaucracy as a whole.
Prev    Next

Comments

Visiting

I'm coming to visit (with my senior project, at Congressman Blumenauer's office) this afternoon! I promise that everyone in my office is very anti-bureaucracy. Hope to see you.

A Second Life

Send by email
One of our clients uses Second Life for training and some instruction.  Why they chose to do so is beyond me, but it is not my place to question the intentions of the client, only to heed the client.
 
This client wishes to import of the larger classrooms into their Second Life world.  I've spent a day and a half fighting with various pieces of software, trying to get the exported Collada model to cooperate with their Second Life importer.  Most frustrating is the difficulty in checking the import, as instead of running the import utility on one of Boora's machines, we've instead been sending the .dae file to the client to test.  They've been sending back the error logs from the imports, which are usually filled with nicely undocumented error messages.  This process takes a good half-hour, so I can't proceed with my theories until I hear back about the last batch.  Sketchup has cooperated the most, exporting a few compatible .dae files.  However, exports from Revit to .dwgs which I then import to Sketchup and export to .daes usually fail.
 
As part of the process of debugging this issue, I've created a number of files directly in Sketchup to check my theories.  I created a very simple file containing a cube and an abstract shape, which successfully imported.  This model didn't contain anything very detailed, but it was nonetheless a good first step.  I also created a simple file that contained intersecting faces and very precisely squashed shapes that may screw up the importer--shapes that are very common in the exported Revit files.  If these fail to import, we may scrap the project as resolving thousands of intersecting faces by splitting the faces at their mutual intersections will likely be too technically difficult or time consuming if done manually.  Still waiting to hear back about the last batch.
 
Prev    Next