Tuesday, March 05, 2019

Teaching English and mathematics to a six year old

My six year old son has learnt reading and writing which opened up a lot of opportunities. While thinking about how I could be more useful to him, I decided to try Duolingo for English teaching and Khan Academy for mathematics. Everyday at 18:30, I sit down with him and he first does Duolingo for 15 minutes on his tablet, and then Khan Academy for another 15 minutes, for a total of half an hour a day. My role is to make sure that he really does the exercises and not play games or watch YouTube and I only help him when he got stuck.

Since both Duolingo and Khan Academy have curriculums that progress according to his level, I don't have to think about what to teach when. Duolingo, besides English, also improves his reading and comprehension skills. Using the English version of Khan Academy also supports the language effort (of course, I have to translate math questions that have too many words in them to Turkish). The exercises show him the importance of paying attention to detail before jumping to conclusions. Doing something every day is helpful in forming the most useful habit in life: persistence. And finally, he got rid of fearing failure and started to treat failure as a learning opportunity.

Friday, March 01, 2019

Scrum sprints

I propose the following sprints for software development:
  1. Design review sprint (1 week): Review the most problematic sections of software. Output is documentation of reviewed sections.
  2. Implementation sprint (4 weeks): Code is refactored according to design review results, bugs are fixed, features are implemented. Output is software ready for informal testing, i.e. it at least can be built on the test computer and does not crash immediately when run.
  3. Test sprint (1 week): Team decides on test scope, i.e. definition of "Done". Whole team tests the software. These tests are informal and limited to the Done definition. Tests should demonstrate that software is capable of passing the most important/frequent use cases, i.e. software is still in a useable state. Developers only fix bugs during this sprint, no design update is allowed. Output is a tag/snapshot. When you have automated tests with good coverage, you might not need a manual test sprint, because your software will be automatically tested at least once a day.
After these sprints, do a post mortem (1 day) to assess the efficiency of design, implementation and test sprints. Repeat this process until software is at a user acceptable quality level.

Friday, February 15, 2019

Technical reviews and mentoring

Recently a novice engineer sent a technical document for review, for which I was one of the reviewers. When I opened the document, I saw that it was littered with problems typical of a novice: No proper introduction explaining why this document was created, not specifying assumptions, simplifications and constraints, endless rows of data instead of clear graphs (i.e. signal buried in lots of noise), no clear conclusion, missing references, what still needs to be done, i.e. future work. See Why I gave your paper a Strong Reject

I told him that I will not review it. As a grizzled veteran, I find it untolerably boring to provide basic feedback because I have done it a thousand times before.

How can we make both the novice and the veteran happy:

Monday, February 11, 2019

Remote working

Working from home (remote working) is used by many tech companies, e.g. Scott Hanselman from Microsoft. The main counter argument is that people will be less productive. It assumes that being physically present in an office for 8 hours makes you automatically more productive. My argument is that we have to measure productivity by examining the outputs, not by how much time has been spent. Also, design work requires high quality people and those types of people have less problems working on their own.

Risks and Mitigation
  • Not being able to use lab equipment:
    • Pure algorithm/software development requires no extra equipment other than a computer and internet connection. Examples of algorithm development: Guidance and control, navigation.
    • Most analyses are done on a PC with special software, e.g. finite element analysis, aerodynamic analysis.
    • Most equipment is relatively cheap and can be used at home (e.g. medium grade power supplies, oscilloscopes). For the remaining 10% of testing and analysis needs, you go to the lab. Criteria: If the equipment fits on your computer desk, it can be used at home.
  • Social isolation, loss of motivation
    • Assuming a four level hierarchy (team member -->  lead --> coordinator --> boss), organize daily online scrum meetings with tools like WhatsApp / Skype. Team leads meet with team members, coordinators meet with team leads and the boss meets with coordinators.
    • Issue tracking and sprint boards with Jira. Work in pairs with Teamviewer. Document sharing with Google Drive. Code repo with GitHub.
    • Weekly physical meetings at a central office or cafe.
    • Social events: Workshops at a resort, gym memberships, picnics, trekking, camping etc.
  • Distraction by kids, computer games, movies etc.
    • Work at a quite place like a library and use your smartphone as a modem.
  • Not being able to measure productivity
    • As I already said above, this risk exists in physical offices too. The team lead is very important because the lead has to check and evaluate outputs (code, documents etc.) of team members and give them feedback on a daily basis. For persistent reporting, team members enter their daily progress as comments on the issue tracking system (e.g. Jira) which the lead will read. The same method will be used by coordinators to measure productivity of team leads. I assume that the coordinator is also technically adept and peeks into outputs and issue comments. Finally, how will the boss know that the teams are productive and not a waste of resources, especially if he does not have a technical background? This problem is not specific to working from home, so I will not go into further detail here.
  • Leak of confidential information
    • Most (>90%) technical work is not confidential, it is re-using public knowledge. Use designs/architectures suitable for isolating security related parts. Examples: 
      • Capture confidential information in data, not code.
      • Use emulators/simulators to test interfaces with dummy implementations. Most of the logic problems can be detected and resolved with dummy implementations. Test confidential implementations on site.
Advantages:
  • Attractive to talent --> You can select from a better talent pool.
  • Adapt work hours and environment to your personal preferences, reduce interrupts, resulting in better concentration (being in the zone) which increases efficiency by an order of magnitude.
  • Reduction of time wasted in traffic (in my case, 2 hours per day, i.e. 25% of the 8 hour work day).
  • Much better for families with little kids where daycare or dropping kids to school and picking up them up from school becomes a major issue.
  • Drastic reduction of logistics costs:
    • Less transport and related liabilities like traffic accidents.
    • Less office space --> Less building, heating, cleaning, maintaining.
    • Less cafeteria space, less cooking.
    • Fewer lavatory facilities and maintenance.
  • Reduction of city traffic and pollution.

Tuesday, January 29, 2019

How to outsource

The major benefit of outsourcing is to do more with less personel, to be shielded from human resources management issues and concentrate on the product. However, outsourcing work that is not clearly defined (like most research & development work) can be a headache if done haphazardly. By its very nature, most R&D work fails and should be treated as learning experiences. How can you outsource something that will most probably fail? I suggest dividing the task into the following three phases:
  1. Analysis: Concept of Operations, detailed requirements and acceptance test plans are generated.
  2. Design: Design documents and a minimum viable product that implements basic functionality is produced.
  3. Production: The end product covering all requirements is tested according to the acceptance test plan.
Instead of a single contract encompassing all three phases, each phase has its own contract. At the end of each phase, in order to continue to the next phase, both the contractor and the customer have to say GO. After that, the contract for the next phase is signed. The contractor gets paid only for the phase it has finished.

Note that for phases 1 and 2, there are no acceptance criteria for the deliverables, because adding additional criteria will drive the cost up. The contractor could submit a one page document and call it "requirements". The only leverage the customer has during these phases is the threat of not awarding the next phase and blacklisting. Therefore, most of the payment should be done in phase 3. If the total cost of the project is 100%, phase 1 should be 10%, phase 2 should be 20% and phase 3 should be 70%. Due to the relatively low cost, phases 1 and 2 could be awarded to multiple contractors to have some kind of competition.

Dividing the work into three phases protects the customer from mediocre contractors. At the end of phase 1 or phase 2, if the customer is not satisfied, armed with lessons learned and documents / prototype at hand, it can select another contractor. This phase structure also protects the contractor from fuzzy requirements and challenges that turn out to be technically impossible.

Friday, January 18, 2019

Good Variable names

Good code requires minimal comments to understand it. One of the best ways to achieve clarity is to use good variable names. Examples of bad variable names:
  • euler
  • h
  • azimuth
  • acc
Better variable names:
  • eulerRFB321NED2Body_rad: Rotated frame based Euler angles that will transform the NED frame to body fixed frame. Unit is radians. Note that array element order should be 0 = yaw, 1 = pitch, 2 = roll to reduce potential confusion.
  • hMSL_ft: Height above mean sea level. Unit is feet.
  • azimuthCWFromTrueNorth_deg: Azimuth measured clockwise from true North. Unit is degrees.
  • a_bi_NED_mps2: acceleration of body with respect to inertial frame, expressed in NED frame. Unit is m/s^2

Tuesday, January 15, 2019

Job attitude

Recently some novice engineers complained about their work, saying that it was boring. My own attitude towards my work is first and foremost "am I useful, do I add value". If I am not able to answer that question with a resounding yes, I have to find ways to make myself useful. Only after that do I allow myself to ask for more.

If you take initiative instead of complaining, you will go a long way, especially in fast growing environments, where there are many new challenges whose solutions nobody knows yet.

Similarly, if someone outside my workplace asks for my services, my first question is never "how much will you pay me" but "how can I be of help to you, is this problem worth solving".

As long as you keep on adding value, responsibility, respect and money will follow.