Samsung connect auto

If you have been following the samsung announcements during this year MWC, you might have come across the Samsung connect auto. It’s basically a dongle that can plug into your car OBD II port (short for On-Board diagnostics: https://en.wikipedia.org/wiki/On-board_diagnostics#OBD-II), assuming you have one, and turns your can into a connected one.

Interesting concept and product considering all the possibilities that it can offer:

https://news.samsung.com/global/samsung-ushers-in-a-new-era-of-driving-experience-with-samsung-connect-auto

I will use at least to find where I parked my car ūüôā

I’m personally more concerned about the security aspects of such thing. Indeed, Samsung states that security is provided through Knox platform. But I can’t help myself to wonder if it’s good enough considering that it simply creates a gateway to your car. I can already imagine a few scenarios where a hacker can exploit its¬†compatibility with geo-fencing and driver rating to do few things …

What do you think?

Advertisements

Product Management: When less is more [3/n]

Part 3

Keep it simple!

I was reading one of my old school papers about the PDCA principle on quality management, and thought that it’s worth mentioning how it can be generalized on almost every step of the Product Lifecycle Management.

PDCA, also known as Deming’s cycle, stands for Plan-Do-Check-Act. Although, it sounds obvious, you can’t imagine how many people miss these essential steps!

There is also a variant that I like a lot, which is the OPDCA. In this case, the O stands for Observe. Let’s break it down through examples:

Observe: study your environment, your competition, your existing resources (human capital,  your current resources, your potential ones, etc.) Be smart and time-efficient during this step.

Plan: define WHAT do you want to do and WHEN you want it to be done.

Do: I guess (and hope) that I don’t need to explain this one. Just remember to keep it simple by using approaches/tools that will allow you to recover easily/efficiently when you make mistakes (and yes, you will!)

Check: have tools/metrics for testing and validating what you’re doing.

Act: if your check results are not good enough, reiterate. The key phrase: do your checking results match WHAT you want, and if not when will it be the case?

And then you can reiterate. Hence the cycle.

This iterative approach, although it goes back to the 50’s, is the closest thing to current day Agile methods. Both approaches can coexist perfectly.

A fun fact worth mentioning by A. Morrison et al. : “One VP of engineering, obviously oblivious to Deming’s Plan-Do-Check-Act cycle or, as it is known, PDCA, thought the letters stood for Please Don’t Change Anything”.  Please, DO NOT DO THAT!

So keep in mind:

  • Analyzing the environment and the requirements is essential
  • Making mistakes is perfectly normal and natural. Repeating them is … well, you know … To quote one of the most brilliant minds of humanity: Insanity is doing the same thing over and over again and expecting different results.
  • Use the bugs: you cannot prevent ALL the bugs, but you can make your system antifragile* by allowing your self to benefit from them efficiently. Think about how to give your system the ability to report errors and how they can be fixed simply instead of spending too much time bullet-proofing it.
  • Live communication is fundamental, written communication is vital!
  • To quote Einstein once more: If you can’t explain it simply, you don’t understand it well enough. Meaning: If it’s too complicated to be explained, review it and start over.
  • Have a mid-term analysis: short term is simply not smart, long term is not always practical.

To be continued.

* Antifragility is a philosophical concept introduced by N. TALEB explaining how there are systems that can benefit from randomness and error. A great book that I highly recommend!

Go 1.6 is available

Google has released the new version of Golang: 1.6. Here are the major updates:

  • Support of HTTP/2 (https://http2.github.io)
  • Enhancements on the template packages
  • The¬†Experimental support of the¬†vendor directory in 1.5 is now enabled by default. Check this document for more details: https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-rw5t9MxJwkfpx90cqG9AFL0JAYo/edit
  • The runtime¬†detects and reports¬†concurrent misuse of maps. Don’t forget the prebuilt race detector.
  • Major changes to the rules for sharing pointers between Go and C code (if you’re using cgo).
  • Debugging multiple goroutines is way better (the stack backtrace is more human-friendly now)
  • The sorting algorithm has been optimized to run 10% faster.

For more details, check the golang blog : https://blog.golang.org/go1.6

 

Partial pdf export

Despite your editing tool, I guess (and hope) that you always export your document to PDF format. Something I always needed while exchanging my big documents with others is to sending only specific parts.  A cool tool for that is pdftk on Linux (sudo apt-get install pdftk)

pdftk A=input_file.pdf cat A12-13 output output_file.pdf

This will export pages 12 to 13.

Of course, you can always use a pdf printer and select only the page range you’re interested in, just google “print to pdf” if it’s not already available on your system ¬†ūüėČ

Update: I read that Microsoft has added the native support of PDF export on Windows 10.

Product Management: When less is more [2/n]

PART 2

Market analysis :

should describe what is expected from the product. Usually, this happens in the following way: a the product manager supervises the marketing department and describes how to address the clients needs: the Market Requirements Document (MRD) lists these aspects.

Conception:

This happens in two phases: first, the macro level where we translate the MRD into a high-level concept. This is described in a Product Requirements Document (PRD) that lists the product features and main requirements.

Accordingly, the engineering team/analysts detail the PRD into sub features describing the product specifications in a functional way: how should the product behave (not the technical how). This results in a Functional Specifications Document (FSD).

Conception focuses on the “WHAT“.

Development:

Keep it simple, keep it efficient. Products¬†are as the rest: alive and evolving. So, before translating the functional specifications into a technical implementation, consider structuring the product first. For instance, a software product requires a global architecture before start coding, otherwise, you just keep doing the same thing over and over again. This is a simple logic. Think of your architecture as general guidelines that allow you and anyone on the team to see the big picture, the map. And when you’re lost (and trust me, you’ll be), you just go back to that.

Just starts by drawing your concept¬†and highlight your system components and actors. From that point on, you just define how each part should interact with the rest. Don’t overdo it, keep in mind that it’s a guideline. Macro first then Micro. Go from the general to the specifics. It easier to understand this way.

It’s easier to describe this through an example. For instance, if you’re building a software that manage multiple users in a networked environment to access a common database and share stuffs on it through a custom policy managed by an administrator.¬†Your actors will be: client user, server administrator. Your system components are a client, server, and a database.

arch - New Page

Keep in mind that when you’re architecture is simple, it allows you to evolve your product without breaking it.

From here on, you can define specifics guidelines on your components according to your constraints: choose languages, define interfaces, wireframe GUIs, etc.

Development focuses on the “HOW“.

Validation:

Let me put it in one sentence: an untested system is not a working one. It’s always better to find your bug, whatever its¬†criticality, when it’s still inside your company, rather than let it slip to your customers. As a general rule of thumb, customers are not forgiving.

To be continued in the next part.

Product Management: When less is more [1/n]

PART 1

 

Respectfully, I think that an expert has a tendancy to adjust a problem to his/her know-how instead of adjusting to the matter in hand. That being said, it is not always the case.

In this context,¬†I don’t consider my self¬†an expert in anything and I try to keep it¬†that way. I believe that by doing so, I put less constraints on my approach, and¬†allows me to keep an open-mind and my objectiveness for a problem analysis.

In the specific case of a product development process, I’ve learned that there’s no perfect way to do things. It always depends: on your market, resources, budget, history, etc. In fact, I dare to say that there’s probably as many ways as persons in a company.

Less is more in this context means that by focusing on a simplified yet complete workflow, we spend less time thinking about the what and how and focus on doing the actual thing.

There’s so many product¬†management tools and methodologies out there, and I’m not arguing about it or analysis their pros and cons here .. In the end, they all share the same concepts.

I’ve found that what always works is to study your environment and evolve with it. Your products are alive and evolving, your documents are alive and evolving, I hope that I don’t need to remind you that your team members are alive and evolving.

Most of all, I’ve noticed that people ofter underestimate the importance of writing down their thoughts about a product and go directly to the development. For a one-shot thingy, a proof-of-concept, this might work, but then again this is not what we’re talking about here.

Whatever your¬†product is, whatever your management method is, as long as it’s an industrial one,¬†it goes through the same phases (which is eventually a circle):

Market analysis, Conception, Development and Validation

cycle - New Page

Let’s see how these parts interact.

To be continued in this next part

 

Go Vs Rust

The two hype and hot computer languages today are Go (Golang) and Rust. I’ve been discussing their pros and cons for many times with my colleagues but we finally agreed that they simply are not comparable (at least for now). Here are some of the interesting links I’ve found on this subject:

http://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-competitors

https://jaredforsyth.com/2014/03/22/rust-vs-go/

I’m not a big fan of benchmark, as I know how such tests are biased by design but I’m putting it in anyway:

https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=go

In simple words:

Go: mature, concurrency, simple language, libraries, networking

Rust: low level control, safety, speed, functional features

Personally, I love Python for a simple reason: when I have an idea, I can program it easily test it, and optimize it later (sometimes switch to another language if nice GUIs / high performances are required). On Go, I have the same ease with a great bonus: compiled language, more efficient and with built-in concurrency features.

That’s why I’m betting on Go. Because of with these capabilities, the languages/tools¬†can evolve later, offer a better optimization, even an easier way for a full static linking, maybe support generics (if you’re into such things) while offering a simple and efficient language. For Rust, all-tough I like its¬†concept of safety, I don’t think it can go¬†the other way around.