Saturday, September 8, 2012

The axis of a software person

There are several axis for the skill that a software person should (must) have
  1. Software engineering skills - these are the skills that allow a software person to transform a description of a system to a system and a project that can be controlled and maintained. These skills are:
    • Distilling requirements from the needs of the client. This is a phase where a semantic description of a system is reduced to a syntactic description. Engineers need syntax, as it is possible to build tools that understand and analyze syntactic description of a system.
    • Designing the system - both low and high level design
    • Understanding regulations related to software (e.g., privacy constraints or accessibility rules)
    • Knowledge of development processes - agile or not agile, TDD or testing at the end of each development phase
  2. Software coding skills - these are the skills that allow developers to take a description of  a system and develop something that executes on a computer, these skills are:
    • Programming language(s) - The vehicle that translates neural signals in the developer's brain to operations on the CPU. It is crucial to know at least one, but it is rarely enough. The fact that it is possible to use a certain language to code doesn't mean that it is the right language to choose, turing completeness is not everything. Be versatile, know static and dynamic language, declarative and imperative, functional and OO ...
    • Development tools - understand what your IDE can give you. Know all the features of your debugger, also all of its blind-spots (concurrency...)
    • Development ecosystem - know the libraries, toolkits, and basically everything that is already done, correct and useful
    • Problems avoiding - understand code smells. In my first course on software development the lecturer said "code that is written twice is written once too many" - follow this rule, learn to love refactoring and strive for code reusability
  3. Expertise in a technical domain - knowledge beyond coding. It can be machine learning or information retrieval, usability or DB design, security or concurrent programming. A software person must be knowledgeable in a technical domain, this what separates software person from a code monkey
  4. Understanding of a client's domain - this can be anything - from spacecraft aeronautics to medical devices, it is crucial to understand the client's domain in order to be able to provide a product that solves the client's problem. This knowledge is utilized throughout all the software construction life-cycle. From properly understanding the client's requirement, through giving proper names to variables all the way to building a system that is exactly what the client needs. 
Only by having a proper combination of skills along these axis, a software person is able to solve the tough problems that the client is facing and provide a solution that works the way that the client needs (and not just the technical problems that the client doesn't really cares about).

Saturday, August 25, 2012

What's next for Samsung

The court decided that Samsung had infringed several of Apple's patents, mostly design / user interface / user interaction related ones.

That's good, because shameless copying without acknowledging should be discouraged.

So what's Samsung to do next? as I see it, they can choose one of two paths:

1) The easy way - make the users pay for the infringement by keep on using these patents, raise the devices' price and just give that money to Apple as royalties. As a consequence, there would not be a need to innovate as basically, the problem (how to do good design / user interface / user interaction) is solved, just more expensive to the users.

2) The hard way - make themselves temporary pay for the infringement by investing in innovation. Create better, innovative, brilliant designs / user interfaces and user interaction schemes. Ones that are both better than Apple's and are patentable. This means investment in research, ideation and development, without any promise of success, but with a promise that in case of success, they'll be bigger than Apple (and that's a lot).

Which path will they choose ?

Thursday, May 31, 2012

Big data 2.0

One of the hottest fields in the software industry today is big data. It seems that everywhere you go you hear about it.

In the past, what constrained big data from being a reality was low capacity storage (or the price of storing large quantities of data), once this obstacle was removed, and Moore's law kept on ticking, extremely powerful machines were at reach for everyone, and hardware was no longer an issue.

Once hardware stopped being the bottleneck, it was time for software to stop acting as such. This was addressed by designing and implementing better and stronger analysis algorithms (think of the fields of machine learning and data mining) as well as finding and inventing new visualization mechanisms. These solutions are aiming at taking data and extracting information out of it, either by analytically detecting a signal in the data or by rendering the data in ways that it is easy for the mind to grasp and perform its own analysis.

The problem with these solutions is that they are at best when there is a definite answer to a well defined question. Still, more then often, that answer is relatively flat and abstracts out the complexity of both the answer and the question.

There is a need to find a new mechanism, something that would tell the story of the solution, that would deliver the idea that captures the complexity of the question and the complexity of the answer. This is not something that is found in nowadays computer science - it is not a combination of CS and math (to yield better algorithms) or CS and cognitive psychology / neuroscience (the forebearers of the information visualization and HCI fields).

My  guess is that it would be a new field, some sort of an hybrid of CS and philosophy. I specifically think that philosophy is the field from which answers would come since one of the key aspects of philosophy is the ability to tell an idea, a real idea,  not just a story (this is the focus of literature) or express a feeling.

When this field is established - it would be big data 2.0

Saturday, April 21, 2012

Trying out Twitter

I'm trying out twitter - look me up at http://twitter.com/yoavrubin

Monday, March 19, 2012

The most courageous code comment ever

This screen capture (taken from here), is part of the code that put Apollo 11 and 12 on the moon. More specifically, it is part of the landing guidance code, so these lines were responsible for the 'put' in the phrase 'put a man on the moon'. I will never write such a mission critical code, I don't know of anyone who will. 

Still, look at the comments in lines 179 and 180... someone really hoped for it to work...

Tuesday, February 21, 2012

At the end of the rainbow

Took this picture a few days ago, I guess that someone found a few leprechaun gold pots on his porch.

Tuesday, February 7, 2012

My book is now published

The book, called "Looking inside a Neural Network", is based on my thesis. It is now published and available, see it here: http://www.amazon.com/Looking-Inside-Neural-Network-Microscopy/dp/3847378686/

Tuesday, September 13, 2011

The Joy of Clojure - a short book review

I'm currently reading the book "The Joy of Clojure". This is a rare kind of book - the kind you don't want to end. It explains Clojure - but not in a "do this to get that" kind of a way, which is the way most technical books are. It does it differently, by almost telling a story that reveals Clojure layer after layer. It does so while keeping the Clojure motto of "no unneeded overhead" - exactly what's needed, no more no less.

Still, if it was just for that, I wouldn't rush to write this short review - there's something else in the way that this book is written, its style is some sort of a combination between an Arthur Conan Doyle novel in the way that it glues you to the page, and a late night show monologue that provides you fun every 30 seconds.

A must read for every software developer - regardless if you ever plan to write a single line of Clojure code, it would just make you think clearer about code in general and specifically about your code.

Saturday, September 3, 2011

A function, JavaScript engine and the single var pattern to declare variables walk into a pub

Addy Osmani had published a very nice post that summarizes various problems found when doing JavaScript code review. Most of the points there worth paying attention to. However, there is one point there that he got completely wrong. When he discussed the problem of variables declared all over the place within a function scope, he suggested to use the "single var pattern to declare variables", basically write the variables declarations like this:

var someData = "testing",
     otherData = "data1",
     moreData = "data2";

This kind of coding will get you into trouble. Try to find the difference between the code above and the code below:


var someData = "testing"
     otherData = "data1",
     moreData = "data2";

Found?

let's add to the first snippet the scope of each variable:

var someData = "testing", // local within the function
     otherData = "data1", // local within the function
     moreData = "data2"; // local within the function

Now let's do the same for the second snippet:

var someData = "testing" // local within the function
     otherData = "data1", // global
     moreData = "data2"; // global

Big difference, but why?.

Answer: Take a look at the "testing" string. In the first snippet  it is followed by a comma, whereas it is not there in the second snippet. That's all, one comma.

Both snippets are valid JavaScript code, it just happens that even though JavaScript has a C like syntax, it does not require to have a semi-colon at the end of each line, the JavaScript engine will add it if missing.

So the second snippet is actually:


var someData = "testing"; // local within the function
     otherData = "data1", // global
     moreData = "data2"; // global

(note the semi-colon after the "testing").

One more thing to know about JavaScript: when declaring a variable inside a function without the var keyword, it is defined as a global variable.

Now go and find that little comma somewhere in your code, at 1:00 am , a few hours before delivery.

I prefer the simpler approach to define variables, and do the following:


var someData = "testing"; // local within the function
var otherData = "data1"; // local within the function
var moreData = "data2"; // local within the function

You can say that it is less elegant, but it is much less error prone, much more descriptive of what you want, can save hours of looking for a comma and simply put, it is just a simpler code. Just remember that beauty is in the eyes of the beholder, and to me, in code, simplicity is beauty .