Category Archives: Engineering

So many different, poignant ways to Remember

November 11, 2023Engineering, History, Uncategorizedadmin

“When all the guns fell silent….”

Today is Remembrance Day, where on the eleventh day of the eleventh month, at the eleventh hour, we commemorate those who served and died in war. The wars of the past century are almost too numerous to count, and the human experience is complex and varied. We had the privilege today of experiencing parts of four similar but very different commemoration ceremonies.

The first was at the war memorial for the 48th Highlanders. There was a brief parade from near the legislative building, with numerous soldiers, accompanied by pipes and drums[1]. This was followed by a surprisingly poignant speech by (I presume) the head of the war monuments commission about the monument itself, which was commemorating its own 100 year anniversary. He noted that monuments are designed and built to appear (and to be) timeless and eternal, but over a hundred years (and often more), there is the addition of battles and names to commemorate (and the inevitable restoration work), such that the monuments have their own history as well.

There was also the beautifully sung ‘Oh God our Help in Ages Past‘ hymn, where we could see the lined up veterans reading the program and singing along, but I could only see a group of young soldiers singing to comfort themselves and each other in the trenches.

To me, Remembrance day has always felt like it should be a poignant and simple ceremony, where there are a few simple words to trigger the poignant memories, followed by silence to fully ponder them.

As reported in the Manchester Guardian, 1919:

“The hush deepened. It had spread over the whole city and become so pronounced as to impress one with a sense of audibility. It was a silence which was almost pain … And the spirit of memory brooded over it all.”

After the hymn, there were speeches, difficult to hear because of the incongruously loud generator (for the sound system) that we were standing beside, so we moved on.

The next ceremony we experienced we had walked through during setup. Surprised by the somewhat subtle but very present security perimeter around the Provincial Legislature, we eventually figured out that it was likely because the Lieutenant Governor (amongst others) would be speaking, along with other dignitaries at the Ontario Veteran’s Memorial.

As we walked around the back of the legislative building we discovered the other reason for the perimeter: Two howitzers set up, ready to give a 21-gun salute. One of the nice young soldiers in the safety perimeter kindly offered us ear protection just before the first gun fired. We demurred, which was likely a mistake, as the first shot startled us (and many squirrels). Through the scurrying squirrels, dissipating smoke, and car alarm sounds, it struck me as jarring that an occasion that was all about commemorating when the guns finally fell silent would include so many guns firing, along with a bomber flyover…but perhaps that helps remind people of the horrors of war.

After experiencing more than enough howitzer sounds (five), we moved on to the official University of Toronto commemoration ceremony at Soldier’s Tower. This was a very standard Remembrance day ceremony, with the chaplain talking about the act of love that is sacrifice in war. This was however somewhat marred by the sounds of howitzers in the distance, scaring the children in attendance, and making us jump.

There was one moment of humour, however. I do like the sound of church bells, but it is very difficult to exactly tune them. It’s been very strange having a King, after having a Queen almost longer than living memory. This was the first time we’d heard ‘God save the King’ as part of a ceremony, and the out of tune church bells delivering their almost mocking rendition of ‘God Save the Queen'[2] were an excellent counterpoint.

Last on our journey, we stumbled upon some UofT Engineers performing their (apparently) annual Remembrance Day ceremony, complete with specially built temporary memorial[3]:

University of Toronto Engineering Remembrance Memorial, 2023-11-11

Of all the ceremonies, this was the one we identified with: They were engineers, they had built the memorial themselves, the ceremony was small and personal, and there was clear counter-cultural representation.

I thought the quote[4] they chose for the memorial (pictured above) was very important for Remembrance Day (and indeed any day people talk about the ‘Glory’ of war or its self-sacrifice):

“My friend, you would not tell with such high zest
To children ardent for some desperate glory,
The old Lie: Dulce et decorum est
Pro patria mori.”

It speaks to how in war, death is gross and horrific. Wilfred Owen was talking about the horrors of watching your friends die from a poisonous gas attack, but it can just as easily apply to death from anything else.

I think we do ourselves a disservice, especially in a time when war is again raging in Europe, to speak of the glory of war, or dying in war, particularly as a method of convincing people to participate. I believe that as mature individuals (and as a mature society), we can understand that war is horrific and terrible, and gross, but still have the maturity to understand that it is still sometimes a necessary sacrifice for freedom.

[1] I mostly know the 48th Highlanders through the excellent musicianship of their pipes and drums.

[2] It will always be ‘God Save the Queen’ to me.

[3] Another past memorial.

[4] ‘Dulce et decorum est‘, by Wilfred Owen

“Oh, that’s a Fun Failure Mode!”

August 7, 2023Engineering, Nostalgia, Uncategorizedadmin

“Oh, that’s a fun failure mode!” I was talking with a friend of mine recently, and they were talking about a technical problem they were solving[1], specifically about the failure mode that they had seen, and before they could explain their solution, I made the exclamation above.

Failure modes have always fascinated me. I don’t know if that’s a cause of or a result of[2] me going to engineering school[3]. I remember being fascinated (and appalled) by the video and story of ‘Galloping Gertie‘. The torsional twist as a reaction to wind and subsequent failure mode[4] is an image I’ll never forget.

Our undergrad bridge-building course professor[5] seemed to also be very interested in giving us images and experiences of materials actually failing. My favourite was his demontration of the failure characteristics of steel cable. In class, he showed us a diagram similar to this one:

Typical stress vs. strain diagram for a ductile material (e.g. steel). Shows the linear elastic region, strain hardening, and necking leading ultimately to fracture. Source: Wikipedia user Nicoguaro — Typical stress vs. strain diagram for a ductile material (e.g. steel). Shows the linear elastic region, strain hardening, and necking leading ultimately to fracture.

Source: Wikipedia user Nicoguaro

Notable parts of this stress-strain diagram include but are not limited to:
– The ‘elastic region’, amounts of stress/force/pressure where the material will stretch but return to its original shape and size[6]
– The ‘strain hardening region’, where the material will adjust and become somewhat stronger. (This may be undesirable)
– The ‘necking region’, where the metal/material starts to lose strength because the atoms can no longer fill in the gaps, causing narrowing of the cross-section (the ‘necking’), eventually leading to fracture, where the material fails

The demonstration included measurements of the deformation of the steel, using a precise length measuring device[7] to provide numerical measurements. Such a device is required, because the deformations we’re talking about are tiny, due to the large Young’s Modulus of steel.

Another demonstration was using a jug of water to break a wooden dowel. The dowel was fixed to a desk, with one end extending (cantilever-style), where the jug was hung at various points. This was intended to show how the torque[8] (of the mass of the hanging water times the distance from the cantilever point) would increase the force, leading to eventual failure of the dowel.

At least that was the intended demonstration. The dowel was so flexible that it bent downwards far enough to minimize the amount of torque/force, preventing it from breaking. So instead, we got to see a failure mode of the intended failure mode instead (and learned something about the resilience of trees!).

Perhaps most memorable was witnessing a failure mode of the professor, who, discontented with his dowel not failing in the experiment, broke it himself over his knee, showing us both the actual failure mode of wooden dowels and how frustration and anger can contribute to engineering failures.

For a great explanation of the different failure modes of different types of materials, especially what it is that makes wood so resilient, I recommend the textbook we used in this course:

The New Science of Strong Materials: Or Why You Don’t Fall through the FloorJ.E. Gordon, Philip Ball (Introduction)

Both of these demonstrations left strong impressions on me. I still remember them more than 25 years later (and I suspect many of my classmates do as well).

Given how visceral and effective these demonstrations were, it would make sense to work out a (reasonably) full set of reasons that engineering[9] projects fail, and create demonstrations and labs based on those, so that the students have those visceral memories to call upon, to warn and inform them.

But what is that set of reasons that engineering projects fail? How do you categorize and teach failure modes systematically?

That’s a question for next time! (Spoiler alert, it will probably involve the ‘swiss-cheese model‘.)

[1] It was a type of problem that I had designed a system to avoid in the past, so it was kind of cool to see an instance of it ‘in the wild’, so to speak.

[2] Or both!

[3] Or growing up with a parent as an engineer

[4] And the poor dog!

[5] Thanks, Prof. Collins!

[6] For those who have been following the news recently, this is one of the reasons that steel is used for pressure vessels such as submarines.

[7] I was originally going to suggest that this was some sort of strain gauge, but if my memory serves me correctly, I remember a dial moving showing deformation. If anyone knows the type of device typically used for such a test, please comment below!

[8] This may have also been the lesson where I learned the second meaning of the phrase ‘Every Couple has its moment‘.

[9] I’m using the word ‘engineering’ here because all of the demos I talked about were related to mechanical engineering/bridge building, but much of this will apply to software engineering as well.

Links to image on Wikimedia Commons, Creative Commons license available there:
Stress/strain curve

S’s note to me, to help me write this post: “Please pick two failure modes and write about them! Then you can add a bonus failure mode, which was you getting overwhelmed by the number of possible failure modes and timing out before writing anything. “

Why do your legs only get wet when you walk? A guide to rain physics and geometry:

July 26, 2023Analysis, Engineering, Idle Speculation, Science!, Uncategorizedadmin

So, I was out for my morning walk today, and it started to rain. Luckily, I had planned ahead and brought my umbrella. I opened it up, and was standing there, enjoying the rain…and then I started to walk, and my legs started to get wet. I stopped, my legs stopped getting wet, I started walking, my legs got wet again.

The question is why?

I narrowed the problem down to the following variables:
– Height of the person (technically, the height of the edge of the umbrella)
– Walking speed and wind speed (I’m putting these together for reasons you’ll see later)
– Size and shape of rain droplets (this is to measure terminal velocity)
– S also added ‘size of umbrella’, but I’ll address that in the assumptions section

This is a lot of variables, so let’s make some assumptions:
– The human in question is about 2m tall (accurate within 5%)
– The edge of the umbrella is about 2m from the ground (accurate within 10-15%)
– The edge of the umbrella is about 25-50cm from the front of the leg horizontally
– We count the leg as getting wet as when the rain hits the front of the leg just above the ground
– Length of a step is about 80cm (as per this page)
– Raindrop terminal velocity is about 20m/s, as per this graph:

Graph of 'rain drop terminal speed' vs. 'rain drop radius', from Wired "How Fast Is Falling Rain?", August 29/2011 — Graph of ‘rain drop terminal speed’ vs. ‘rain drop radius’, from Wired “How Fast Is Falling Rain?”, August 29/2011

– Wind-speed is negligible, as per this chart from Environment Canada, showing that wind at the time in question (9am) was about 2km/h, from the North:

Table showing weather data for Toronto for 2023-07-25. Relevant part is showing 'Thunderstorm with light rainshowers' and 'Wind 2km/h, N' at 9am. — Table showing weather data for Toronto for 2023-07-25. Relevant part is showing ‘Thunderstorm with light rainshowers’ and ‘Wind 2km/h, N’ at 9am.

Now on to the math!

We can easily show that with negligible wind, rain falling straight down will not hit the legs.

But assuming 90-degrees from ground vertical legs, what wind-speed would be necessary to rain on them?

At 20m/s, the rain would need to travel 0.25m or 0.5m horizontally as it traveled 2m vertically, or a horizontal wind of about 20m/s * 0.25m/2m = 2.5m/s or 9km/h for 25cm of umbrella overhang to 18km/h for 50cm of umbrella overhang.

So it turns out that the wind-speed was actually really important, as you can see that at other points today, it alone would have made the difference.

Now, what happens when we start walking? There are two factors at play here:
– Walking speed
– Extension of the leg forward out of the protection of the umbrella as you take a step

So we have to add some more assumptions:
– Assuming an average walking speed of about 5.4km/h or 1.5m/s
– Assuming that the toe to toe per step distance is 0.8m (from above), assume that at maximum extension, the tip of the leg is 40cm ahead of the body

Using the wind-speed calculation above, we can see that 1.5m/s of forward motion would only counteract about 1.5m/s / 20m/s * 2m = 15cm of umbrella cover, not enough to make your legs wet.

However, if your leg is 40cm ahead of your body, that would be enough if your umbrella was any reasonable amount off ‘exactly centered’ over the front of your body, and if your leg is 40cm ahead, and your walking speed adds another 15cm, that is enough to counteract even perfect vertical umbrella placement (40cm + 15cm > 50cm).

My experience this morning suggests that either the rain was falling more slowly than 20m/s, I was walking slightly faster than 1.5m/s, or I was resting the umbrella diagonally over my shoulder (most likely). This would have given me the approx. 25cm protection above, and caused my legs to be wet only while I was walking.

How would you calculate this? What would your assumptions be? Have you experienced this? Are you going to test this the next time it rains? Are you as surprised as I am that leg placement and step length are much more important than walking speed (as long as you’re only walking)?

Let me know what you think in the comments!

Some More Management Roles

January 6, 2020Agile, Engineering, Organizing Systems, Software Developmentadmin

A few years ago, I talked about some management roles, specifically how the traditional ‘Team Lead’ role could be de-convolved into five different roles:

Performance Manager (Worker Evaluation)
Estimatrix (Estimator)
Product Owner (Prioritization)
Scrum Master (Removing Obstacles)
(People) Development Manager (Development Conversations)

At the time, while I’d been running important teams in my organization, it was still a relatively small organization (each CEO knew me by name), so the role and significance of each team was more clear (or at least had been justified by someone before me).

Since then, I’ve learned a little more about what is important in a large organization, and I have some more roles to add. The above management roles have more to do with day-to-day management of a team, and assume that managing upwards and managing long-term are taken care of elsewhere. (Theoretically, they are probably most likely part of the ‘Product Owner’, but most likely they would be part of the ‘reserve power‘, and would devolve to whomever was considered ‘highest’ in whatever organizational hierarchy was present.)

I had also been blessed with excellent technical leads on all of my teams at all of the places I’ve worked, enough so that I didn’t think to explicitly call out ‘Technical Lead’ as one of the ‘traditional’ management roles.

(So now, we have six):

Technical Lead (Software Architecture & Implementation Decisions)
Performance Manager (Worker Evaluation)
Estimatrix (Estimator)
Product Owner (Prioritization)
Scrum Master (Removing Obstacles)
(People) Development Manager (Development Conversations)

(There are also some questions about the exact line between ‘roles’ and ‘skills, for example: ‘Running a Meeting’ ‘Presenting engaging presentations’), so I will include them for completeness, even though they bleed into many of the other ‘roles’.

As mentioned above, the roles below would fall under some combination of:
– ‘Product Owner’ (because they involve working with people or groups outside/above the team in question)
– ‘Scrum Master’ (because the team would notice that they were blocked or impeded by not paying attention to a certain type of issue, and might be perceptive enough to up-level the discussion to a more general/role-based one)
– ‘Reserve Power’ (roles or tasks that are automatically put under a traditional ‘Team Lead’, but no one really considers them separately, even though they take real time and effort)

Anyways, here are some other longer-term and/or more upward-facing roles to add to the above:

Milestone setter
Team Vision & Planning
Recruiting, Interviewing, & Hiring
Team compositions planning/Team Development (this is development of the team as a whole)
Building relationships (travel, phone, random 1:1s)
Running Meetings
Preparing & presenting engaging presentations
Tech architect (Longer-term decisions about code structure)
Code reviews (this would likely fall under ‘Tech Lead’ above, but ‘what is good enough’ would likely fall under the next line, ‘Quality decision-making’)
Quality decision-making (how good is ‘good enough to ship’?)
Quality Assurance & testing
Asking for resources
Team Champion, in charge of Dog & Pony shows[1] (Why is the work that the team does important?)

Some of the above roles are systematized, automated, or otherwise circumscribed by processes in larger organizations, for example, they may have specific processes for project planning, or for recruiting or development conversations.

But still, there are a lot of these. This suggests that either teamwork is super-complex, and requires too many different things to easily handle without tools[2], or there must be some way of grouping them into meaningful ‘roles’.

So, how do we group them? We could group them into the familiar Agile ‘Technical Lead’, ‘Scrum Master’, and ‘Product Owner’, but that just really puts us back where we started, shoehorning roles into boxes that don’t quite fit, or with a bunch left over.

Fundamentally, all of the above roles are some combination of tasks and making different kinds of decisions.

I’ll do what I can to define, codify, and group them tomorrow.

[1] I am somewhat flip in my naming here, but in any large organization, any team should have a story for how they are planning to remind the management structure of why they are important. This serves a number of functions:
0) The obvious ‘remember who we are and what we do’
1) It’s a good check-in, to make sure that what they are doing is actually perceived as important
2) It’s good practice for the inevitable re-orgs in any large organization, or even if one’s boss changes because they leave for another position or organization

[2] Like checklists, or more advanced tools like JIRA and wikis.

On the Importance of ‘Technical Debt’

January 1, 2020Agile, Economics, Engineering, Organizing Systems, Programming, Software Developmentadmin

A couple of years ago, I was talking with a good friend of mine, we were talking about the difficulties of prioritizing the maintainability of software in a large organization development context.

And so, logically, the concept of ‘Technical Debt’ came up. Interestingly, he had never heard the term before[1], although as soon as he heard it, he grasped the importance.

(I remember it as being a really inspiring conversation, but sadly, my notes from that day don’t well capture what I found so inspiring about it. 🙁 )

Although the concepts of ‘clean up after yourself’ and ‘do it the right way’ are likely as old as human civilization, it was likely only after systems reached a certain level of complexity that the concept of ‘Technical Debt’ was really useful. There is a limit to how complex a mechanical system can get[2], and most other systems are amenable to human factors and psychological safety solutions.

It’s also interesting to think about what is different about software, that makes it: A) possible to make a working product with large (including conceptual) defects, B) Useful to ‘go into debt’ to get a product out the door faster (or more cheaply).

One wonders how much it is the sheer complexity of software systems, the number of interacting modules, or perhaps the number of layers involved, from OS to dev_tools, to language, to standard libraries, to 3rd party libraries, to user-made helper functions. Perhaps it is just that one can ‘go into debt’ in the uppermost layer, because there exists a good foundation.

It could also simply be that software is an automation of so many smaller tasks, that any human system as complex would have similar useful concepts of debt[3].

Doing a little bit of digging, it seems that the concept was first termed ‘debt’ sometime in 1992[4], but it was not until later that it was termed ‘Technical Debt’.

Articulating the concept of ‘Technical Debt’ has a number of important benefits:

1) It puts a name on the category of ‘things we want to clean up in our code’, adds an urgency, and calls out more precisely why this is important.

2) It links the concept of ‘do things the right way’ with ‘Business’ concepts of money. This enables much better CTO-CFO conversations, allows better and more informed project funding decision making, and (hopefully) enables better and more structured funding for Technical Debt reduction[5].

3) It enables conversations in the moment, during architecture conversations and code reviews (and everything in between), where the parties involved can directly weigh/balance the time/resource costs of proper implementation with the opportunity costs of delaying time to market (or MVI/MVP[6]).

It will be interesting to see how organizations (and organizational decision-making) change as this concept spreads from ‘pure’ software companies.

[1] We theorized that this was because he had grown up in Hardware companies.

[2] I am not a Mechanical Engineer, and I’m happy to hear counterexamples, as well the conceptual frameworks used to address this… 🙂

[3] Such as ‘Organizational Debt‘.

[4] https://www.martinfowler.com/bliki/TechnicalDebt.html “As far as I can tell, Ward first introduced this concept in an experience report for OOPSLA 1992. It has also been discussed on the wiki http://wiki.c2.com/?ComplexityAsDebt.”

[5] My favourite label for this is the ‘FBI’ list[7], as in ‘Can you F****** Believe It?’, passed down to me by an executive from a famous Canadian software company.

[6] ‘Minimum Viable Increment/Minimum Viable Product‘, from various implementations of Agile theory.

[7] Things that might linger on a list like this include things filed ‘Too Dangerous to Fix’, which are often interesting memoir fodder.

One Way to Run a Hackathon

November 16, 2017Engineering, Internet Culture, Organizing Systems, Software Developmentadmin

A place that I used to work ran periodic ‘Hackathons[1]’. After trying to describe them to various people it became clear that there were a number of different definitions of what a ‘Hackathon’ could (or should) be, so here’s my description, with some thoughts as to why structuring it this way might be a good idea.

Definition?:
What is a ‘Hackathon’? It’s a lot of different things to different people. Most definitions I’ve seen see it as an opportunity to spend a day (often 24 hours, or a weekend) building something that they wouldn’t normally build. The thing built is not necessarily a ‘thing’. It could be a website, and app, some other type of computer program, it could even be an organization. The important thing here is that whatever is created/built is taken from the concept stage to working prototype with at least some useful feature(s) by the end of the hackathon.

Purpose:
Why do you want to have a Hackathon? The ones that I’ve been involved with were an opportunity for people in a software organization to try something a little different for a day. Some reasons they did it:
– Learning a new skill or programming language by building something ‘real’
– ‘Scratching that itch’, solving some problem that they never quite get the time or priority to solve in their day-to-day
– Working with people that they don’t normally work with
– Building a full product (instead of working on a tiny piece of a huge system)
– Building a visualization tool
– Doing something totally different

Those involved generally seemed to greatly enjoy the experience, the chance to work on something different, to push themselves in a new and different direction, and perhaps the chance to receive the acclaim of their peers.

How did it work?:

There was a committee formed to organize the Hackathon. They were responsible for:
– Publicity
– Getting buy-in from management (this had already happened, so this part was relatively easy)
– Convincing judges to judge the competition (These were usually senior people in the organization who were not part of a ‘hack’)
– Organizing the various parts of the event
– The ‘pitch’
– The presentations
– The prizes
– The voting for the ‘Audience Choice’
– A/V and some method for telling presenters their time was up (we used a stop light)
– Finding sponsors for any ‘Sponsored Hacks’
– All of the various other small things required to run an event like this
– Buying the pizza for the party after the presentations

How often did they happen?
– The Hackathons happened once per quarter, generally in the middle of the week

Schedule:

During the weeks before:
– Publicity, book rooms, perhaps plan food, plan A/V, location, etc.

A couple of days before:
– Run the ‘Pitch Session’
– Provide a place (usually a wiki page) for people to join groups following the pitches

The first day of the hackathon (The hackathon would run noon to noon, with presentations 3-4pm the following day):
– Start the hackathon, giving any support where necessary

The second day of the hackathon:
– Collect presentations, so they can be presented in a timely manner
– Collect the judges, so they can judge the competition
– Run the presentations
– Run the ‘Audience Choice’ vote
– Count the ‘Audience Choice’ votes
– Distract the people with pizza while the judges are deliberating
– Help the judges present prizes

Some more details:

A ‘Pitch Session’ is:
– Each person gets one minute to talk about their idea, in the hopes that they can attract a group of people to work on it with them. There was a rule that teams had to pitch something if they wanted to win ‘best hack’, to encourage them to participate in the pitches and include others

How are teams formed?
– Teams can be of any number of people, but we never saw a team of more than 12 people or fewer than 1 person[2].
– To encourage different parts of the organization to work together, each team would be awarded points for each group represented in the team. Including someone from ‘Customer Experience’ or ‘Marketing’ would be worth three points, while including people from Engineering (the expected default for a hackday) would be worth 1 point
– Teams, once formed are added to the hackday webpage, for posterity, and so people can coordinate (and so the organizers can coordinate collecting all of the presentations)

What happened during the 24-hour Hackathon period?
– During the 24 hours of ‘hacking’, people generally put their project work aside and work on their hacks. Some people were given more or less time to do so, depending on their particular management chain and the urgency of their specific work at hand. Of course, if a production issue cropped up in the middle of the day, that would have priority.

How did presentations work?
– Each team was given 3 minutes to present. Luckily, we had a traffic light that was repurposed to give an easily visible signal to presenters when they were running short of time.
– There was generally an audience, of the other people hacking, the judges, and whoever else wanted pizza later

How were they judged?
– ‘Best Pitch’ (a friend of mine routinely won this part, due to his uniquely hilarious presentation style)
– This was generally awarded based on presentation originality and style
– ‘Most Productizeable’ (Which hack was easiest to productize for customers, either internal or external?)
– ‘Best Hack’ (this is the ‘best overall’ category)
– Not necessarily the one that won any other category, but the best overall
– ‘Best Presentation’
– Similar to ‘Best Pitch’, but generally a higher level of polish (and humour) is expected
– ‘Best Sponsored Hack’
– This is like ‘Best Hack’, but restricted to the specific sponsored category
– Hacks would be graded on the criteria above by the judges, IIRC on a 1-10 scale. (There may have been other criteria which were then rolled up into the categories above. That would be up to any event organizers, should someone wish to take these instructions and run with them.)

How did ‘Sponsored Hack’ work?
– This was a later innovation after some people saw the power of the various hacks that had taken place.
– A person or persons within the company would put up money for prize(s) for the best hack that would fulfill certain criteria. There was one hack to link a system to a particular enterprise solution, and one hack to use a new internal API that had been developed
– There was generally only one ‘Sponsored Hack’ per hackathon, and it was a bidding contest to determine which one would be the official ‘Sponsored Hack
– We found that having super-clear criteria about what constituted a ‘successful hack’ was extra important when the prize money for ‘Sponsored Hack’ greatly outweighed the prize money for ‘Best Hack’

What were the prizes?
– Generally gift cards of some type, glory, and a trophy
– The gift cards would be in the $50-100 range for first place. The glory was the really important part.
– Part of the trophy process was the expectation that each group would modify the trophy in some way before presenting it to the next team at the next hackaton
– We had some issues with one of the sponsored hacks when the prize money reached into the hundreds of dollars, because we had not clearly defined ‘When is a hack good enough to be considered a successful hack?’, and the difficulty of the particular hack

What types of ‘hacks’ did you see?
– There were a number of visualizations of various parts of the system
– There were a number of creative front-end interfaces for various parts of the system
– There was a one-line fix to a bug, in a effort to win ‘most productizeable’ by already being in production
– There was a musical number
– Once, the entire team of interns worked together on a hack
– We had an issue with not being able to tell whether our non-bookable meeting rooms were occupied, so one group made some lights with door sensors to quickly communicate down the hall that a room was occupied or not
– And many others…

Pleaes drop me a line if you want to run one of these. They’re a lot of fun, and can really help people get to know others and build an ‘esprit do corps’ in an organization.

[1]Unrelated: ‘Stupid Hackathons‘, which have a *totally* different ethos…

[2]Even the ‘Automated PowerPoint Presentation’ hack required someone to give the presentation.

Energy Efficiency and the ‘Rosenfeld Effect’

February 10, 2017Economics, Engineering, Science!admin

Art Rosenfeld passed away two weeks ago. Most people would not remember him, but they have been affected by his simple observation in 1976 that a “proposed nuclear power plant would not be needed if refrigerators were required to be more efficient.”

Here you can see the effects on the energy efficiency in the state of California:

"The Rosenfeld Effect." — “The Rosenfeld Effect.”

Note how the energy expenditure per capita flatlines from the time he made the observation above. It was never one thing, but a lot of little things Turning off lights at night, higher efficiency furnaces and fridges and stoves. Higher efficiency lighting. Better windows.

These are the kinds of things which make a huge difference in aggregate (and he was a master at expressing how much of a difference each of them would make singularly, such as spending 20mins with light switches saves 100 gallons of gas over the weekend). These are the kinds of incremental changes which are slowly reducing the scourge of cancer[1]. These are the kinds of things which can reduce changes to the climate.

Thanks, Art. Let’s keep working and doing things a little more intelligently every day.

Art Rosenfeld, California’s Godfather of Energy Efficiency, Dies at 90

[1]This is a fascinating topic. Check out these graphs: https://www.google.ca/search?q=cancer+mortality+rate+historical

1997: The year they made Contact

January 9, 2017Engineering, Nostalgia, Organizing Systems, Reviews, Science!, Space!admin

20 years ago, I watched Contact in the theater with my family[1]. Tonight, I watched it again, with S.

To me, it held up well as a movie. All the characters were believable, and the science and the effects were well within the normal parameters of suspension of disbelief.

What struck me[2] was how hopeful a movie it was, that our better natures would win out, that our endless curiosity would take us places we’ve never imagined.

[Note that spoilers follow]

It’s always interesting the things you remember 20 years later. “Why not make two, at twice the price?” The destruction scene. The prime numbers sounding so ominously alien from the aether. The speaking through her father. The 18 hours of static[3].

Interestingly, I had remembered that 18 hours of static as being the vindication at the end of the movie, that she was not crazy, that something had indeed happened, but I had forgotten how much it was covered up.

The one (gaping) plot hole I had missed the first time around was the absence of study and testing before a human was sent through the machine. If you look at the history of the Apollo program, you see that it was preceded by Mercury and Gemini, with dozens of sequential missions, each testing new parts, to make sure that each part of the system and plan were well-enough understood to ensure successful missions. The idea that they would build a half-trillion-dollar system in Contact and not fully study it (especially if it’s generating strange EM radiation) before sending a human through it ‘strains credulity’. Even the EM it’s radiating would be a fantastic discovery for humans.

But I can understand how they would cut out things to make a move that was watchable, and which was able to spend its time focusing on the humans in the story.

The alternative view of events that the NSA directory was trying to convince people of at the end of the movie was reminiscent (for me) of the big con[4] at the end of ‘Watchmen’, albeit at the opposite end of the hope-fear axis.

Apparently, like Bladerunner, the ending was supposed to keep your doubt alive as to whether the events she experienced had actually happened. To me, it didn’t, as 18 hours of static (and whatever metallurgical data they could get from the sphere) would be enough to prove the story.

I laughed, I cried, I am full of hope. A new year dawns. Time to use that hope to build something meaningful, starting with some words.

[1]We immediately followed it with Men In Black. I’ll leave it to you to enjoy this juxtaposition.

[2]If you’d read or watched any Carl Sagan, this would probably not be surprising. “The sky calls to us. If we do not destroy ourselves, we will one day venture to the stars.”

[3]I had remembered it as 18 minutes.

[4]In ‘Contact’, it was posited that a billionaire had faked first contact to inspire humans to push themselves outwards. In ‘Watchmen’ (the graphic novel[5]), Adrian Veidt fakes an alien invasion to scare humans into working together against a common foe.

[5]’Watchmen’ the movie simplified the plot to have Doctor Manhattan be the scapegoat. this lead to a much tighter movie, but slightly less appropriate for my analogy, however much he played with space and time.

Why the Headphone Jack Must Stay

September 10, 2016Economics, Engineering, Internet Culture, Musicadmin

Yesterday, we had a date night, and over dinner, we thought “Wouldn’t it be nice to watch Contact? Neither of us have seen it since it came out, almost 20 years ago.”

First, we opened up Netflix, and searched for ‘Contact’. It wasn’t available there, but Netflix said it could show us movies similar to it. (It also showed us ‘Star Trek: First Contact” as an option, more on that later.)

So, we try iTunes. We’re trying it on my computer, because S’s Mac has mysteriously stopped talking to our USB speakers. Fast-forwarding through the standard iTunes bad user experience[1], we eventually figure out how to rent ‘Contact’, the movie, in HD for $4.99. It starts downloading. We hook up the projector, start the movie, and we see the following screen:

This is what happens when you try to use iTunes with your projector. (Not shown: Our USB speakers stopped working just then, too.)

The movie that we just paid money to rent will not play on a display that iTunes was more than happy to play on just a couple of years ago.

Think about what just happened here. We went to the extra effort of purchasing a movie rental, and it is treating us like we’re trying to pirate it.

Doing some quick googling, we determine that we might be able to get the SD version to work with our setup, but iTunes won’t let us change from HD to SD (and keeps trying to download the HD version, despite the fact that this will overfill the hard drive).

So, back to Netflix. We eventually settle on Firefly (a really interesting concept, more on this in a later post). Netflix just works.

Or at least Netflix tries to work. Somewhere during this process, my Mac has silently decided that it should no longer talk to the USB speakers. There being no useful way to debug this in the ‘System Preferences’ menu, we end up lugging my sound system from my computer, which has a headphone jack connector like so:

Headphone jack to RCA adapter. The best way to get sound from your computer to serious speakers.

The headphone jack connect works. We finally start to relax, I start watching Firefly for the first time, then we watch the masterpiece which is Star Trek: First Contact, and go to sleep happy.

Apple has a lot of power, through its massive market share and avid user base. This power can be used for good, such as when it is used to push for selling DRM-free music, but it can also be used for evil, such as when Apple Music deletes music that you have composed.

With the iPhone 7, Apple is using this power to no longer include a standard headphone jack. Now all music, audio, Stripe payments, what have you, will be streamed digitally. It will probably work, it might even work perfectly and for a long time. But at some point, someone will decide to add DRM to that stream, and all of a sudden your music will stop working.

All because Apple decided to remove your headphone jack.

Cory Doctorow also has some thoughts about this.

[1]iTunes standard bad experience:
– You have to search twice in the search bar for it to actually search
– The search function has a pre-defined list of types of media, and it will always show them to you in that order. Compare with the Google search for ‘Contact’.
– If you start downloading a rented HD movie, you can’t switch to the SD version, even if you realize you don’t have enough hard drive space, or the HD movie won’t play because of the HDCP DRM.
– And don’t get me started on how slow it always is.

Burning Man in Pictures 2015 XLVIII: ‘Edal Bump’

August 27, 2016Engineering, Photos, Traveladmin

When we last saw our heroes, they were flying towards their fiery demise and keeping Curiosity company.

Today, we follow them on their random-walk journey through an eclectic assortment of things that Burning Man has to offer.

First, the (slightly creepy) dancing bears! They seemed just a little *too* happy…:

Found! A public service for all of those lost items. Remember, only MOOP[1] is truly lost (and all lost items are MOOP):

Found! (Only MOOP is truly lost at Burning Man.)

As you may guess, Mad Max is a common decorative theme:

Another example of Mad Max-like architecture.

This structure seemed to serve as a warning. Our heroes shied away, after being burned by objects like this in the past[2]:

Needing a breather, they stopped at the Steampunk Saloon:

Steampunk Saloon! (Tents like this are marvelous shade structures.)

On their way again, they biked along the Esplanade, marveling in the experience:

Riding along the Esplanade, trying to capture the feeling. (Also, wide 'playa tires' in the foreground.) — Riding along the Esplanade, trying to capture the feeling. (Also, wide ‘playa tires’ in the foreground.)

Along the way, they passed a strangely-named structure, ‘Edal Bump’:

'Edal Bump'. 'What does "Edal Bump" mean?' — ‘Edal Bump’. ‘What does “Edal Bump” mean?’

Going slightly further, it made much more sense[3]:

'Ah. "P-Edal Bump".' — ‘Ah. “P-Edal Bump”.’

“Bad Advice”, or “Really Bad Advice”? Which would you choose? Which one would you be more likely to follow? Which would be worse?

And then, in the distance, our heroes spot the destination they didn’t even know they were heading towards, The THUNDERDOME!:

Like a rain god, S spots the Thunderdome off in the distance!

Next time, THE THUNDERDOME! Also, up close and personal with Serpent Mother! Stay tuned!

[1]’Matter Out Of Place’, the reduction of which is central to the ethos of ‘Leave No Trace’, a fundamental ethos of Burning Man. Painstaking inch-by-inch MOOP search and removal is a part of every camp’s responsibility. (Another important part of the ethos is avoiding MOOP, and picking it up anywhere you see it during the festival.)

[2]It does bear an uncanny resemblance to the ‘nuclear waste spike field‘, a hypothetical structure to deal with the very real problem of warning future generations about the problems of nuclear waste.

"‘Spike field’: An early idea from the US Department of Energy in the 1990s. The spikes and their shadows would communicate danger, as would warning signs bearing Edward Munch’s 'The Scream' scattered across the site" - http://www.ft.com/cms/s/2/db87c16c-4947-11e6-b387-64ab0a67014c.html — “‘Spike field’: An early idea from the US Department of Energy in the 1990s. The spikes and their shadows would communicate danger, as would warning signs bearing Edward Munch’s ‘The Scream’ scattered across the site” – http://www.ft.com/cms/s/2/db87c16c-4947-11e6-b387-64ab0a67014c.html

[3]Not to mention why there were so many bicycles in the area (although there could be many reasons for that at the Burn).

Sometimes Egregious, Always Gregarious

Sometimes a letter can make a word of difference