Sunday, February 18, 2018

How to use engineering standards

When I mention engineering standards I either get blank stares or yawning in response. During my career spanning more than two decades, I saw that engineers usually fall between two extremes, heroic or bureaucratic:

What benefit do standards provide? They never guarantee the quality of a complex product but if applied correctly, they save the company from simple mistakes. The majority of resources are usually expended on creating the same problem and solving it again a million times. Standards also ease information exchange between engineers. When introduced to the organization for the first time, they increase short term cost but can be profitable in the long run. But never forget that "A Fool with a Tool is Still a Fool".

For high quality complex products, you need good engineers in a company that already has workflows and documentation practices in place. If your product is not complex and you don't care if your company exists for the next 5 to 10 years, you can throw away the standards and just focus on hiring good engineers.

Very few people are in the sweet spot of wise engineers who understand project needs and tailor standards accordingly. Examples of questions related to standards only wise engineers can answer:
  • What is the safety level of the project? This needs a good understanding of the statement of work / technical specification prepared by the customer and affects everything that follows. It might be the difference between going bankrupt and finishing the project successfully.
  • Which standards and sections of standards are applicable? This also depends on the safety level.
  • Which documents can be combined?
  • When a project is already close to completion and due to last minute certification concerns adherence to standards have to be demonstrated to an independent assessor: Which document should be created first? This priority is very important, because most probably, you won't be able to prepare all the documents at the time the assessor shows up on your doorstep. If you have prepared the most important docs, you might gain time and sympathy instead of being labelled as clueless morons.

Tuesday, January 09, 2018

Android Studio nightmares

Today I tried to build an Android Studio that was written by someone else three years ago. After some initial progress I got stuck with Error:java.util.concurrent.ExecutionException: After hours of struggle and fruitless trials, I finally looked at the details of the Gradle stack trace and saw that the top message was Execution failed for task :app:mergeDebugResources  and the bottom message was$NotifierProcessOutput.out.

My problem was due to an image file name ending with .9.png. I changed the ending to .png and the problem disappeared. Thanks Gradle for the cryptic concurrent.ExecutionException (!) This sort of unhelpful error messages is a typical theme when developing Android apps, especially when dealing with legacy code. You can get stuck for days on problems that you could not have foreseen.

Saturday, December 30, 2017

Practical application of the dot product

I recently had to write an algorithm to decide whether two trains (whose movement directions are known) are moving towards each other or not.

When two trains move towards each other the angle between their direction vectors is larger than 90 degrees. If the track was a straight line the angle would be close to 180 degrees, but tracks are not always straight.

I used the dot (scalar) product as follows:

  1. Calculate the dot product of the train direction vectors. This is equal to cos(angle).
  2. If 90 < angle <= 180 (-1 =< cos(angle) < 0), the two trains are moving towards each other
Note 1: If the track is bending more than 90 degrees, this algorithm will not work:
Note 2: If the trains have passed each other just using the dot product won't work, you also have to check whether the trains are in front of each other (let that be another blog post):

Friday, December 22, 2017

How to respond to questions of novice engineers

When a novice engineer comes to you with a technical question, your first reponse should not be answering the question at hand but asking "what are you trying to accomplish" because most of the time the novice will have gaps in his understanding of the job to be done. Based on that misunderstanding, he will try to solve some technical problem, get stuck and come to you for guidance.

By clarifying the higher level goal to be reached, you can be sure that the question is indeed meaningful and answering it will be productive.

Further reading: Difference between novice and experienced engineers

Music: Hallelujah - Pentatonix

Friday, December 15, 2017

Keeping motivation after lots of failures

Software development means getting stuck a lot of times where all your attempts at moving forward result in failure. This affects my motivation and after enough failures, I feel desperate and don't want to touch the project anymore.

One way to overcome this deadlock is to do smaller things with guaranteed success. For example, I improve documentation, draw prettier graphs, make more detailed plans. Scoring little victories shortens my procastination period and I gain enough enthusiasm to tackle the beast.

The 7 Habits of Highly Effective Artists

Monday, November 27, 2017

Mobile Games for Kids

Below is a list of mobile (Android) games that my 5 year old plays on his tablet and I recommend:
  • Minecraft
  • Monument Valley 2
  • Alto's Adventure
  • Samorost 3
  • Cat Quest
  • War Robots
  • Badland 2
  • Contre Jour
  • World of Goo
  • Bowmasters