Apps
Contact
Seminars
RSS FeedMarch 29th, 2012
What’s good for your mobile is bad for your desktop? And vice-versa?
It is perplexing, to say the least, to observe the simultaneous rise and fall of “apps”. Their rate of disappearance from the desktop is eclipsed only by their rate of appearance on the mobile platforms. Currently, both the iPhone and the Apple “markets” list more than 500,000 apps. My sixth sense tells me more may be on the way.
read more »
October 6th, 2011
Steve Jobs – RIP
“We just wanted to build the best thing we could build.” — Steve Jobs
This is a part of 3 favorite quotes by Steve Jobs. This line is the epitome of all successful product development. Best products are the ones that we create that we wanted to use. Whether it is the user interface, the back end, the wires, what have you – it should really be the best, even if no one will ever see it. This strategy is very different the strategy of General Motors, which tried to save money by building auto parts that were outliving the car itself to lower specifications. Well, their stock results are a bit different too.
RIP Steve.
May 3rd, 2011
Rose is a Rose (but name is important in software and algorithms)
Ms. Juliet Capulet: “What’s in a name? That which we call a rose, By any other name would smell as sweet.” Sure, but Juliet was not an algorithm designer, or a software engineer, or a color guesser!
Apparently, naming is HUGELY import
ant when it comes to those non-romantic fields. John McWhorter’s The Story Of Human Language, presents a fascinating example: people of a certain culture have names for colors red, green, yellow etc, but do not have a name for color blue. Let us call them NoBluez, and let us call ourselves NoCluez for the time being. The NoBluez people see colors just fine, just like you and me, but they don’t have a ready name for the color we call blue. On the other hand, they do have two different names for two shades of yellow, that we normally call just yellow. Let us suppose that their names for the yellows are yellow (the light one) and izaga (the dark one). An experiment is conducted when colors are flashed quickly, and the people are asked to name the color. Although the NoBluez people and the NoCluez people are able to name the colors correctly in all cases (they are all home sapiens after all), still, the NoBluez people have a certain delay in finding and calling out the color blue. NoCluez people, on the other hand, show a delay in calling out the color izaga. Merely, the naming of the colors, has an impact on how quickly we can recognize it.
Nothing in algorithms, or in software engineering could be a more appropriate lesson. If you are going to have a fruitful communication with your team mates, and you are going to make sure that everyone understands and uses the newly written method called “processIt(boolean b)”, then good luck to you! While you may be able to tell everyone today what the method does, the chances of your method standing the test of a few weeks time, are basically zero. Someone will write a worse mouse trap, but name it better (for example, “synchronizeCalendars (boolean inclPastEvents)”), and that is the method that everyone will eventually use.
But that is not all of it. It doesn’t merely affect the usability and recognition of the method. Using a good name helps the person writing the code or the algorithm as well as you think through the logic and the various components and subsystems. Especially more so, when you have a system that is bigger than a few lines. For example, consider the attached MapReduce flowchart (courtesy Lukas). Naming each of those steps appropriately: “split”, “schedule”, “combine” is helpful in going through the motions of designing.
October 15th, 2010
FogBugz, Scrum and Agility
I have been using FogBugz for a long time, but at NTELX, we recently started formalizing use of Scrum within FogBugz.
Have come up with following tips for anyone who is intending to use an agile process within FogBugz:
- Use a tag for each sprint.
- Enter the sprint tag into each FB case in that sprint.
- Have a Wiki called “Scrum Sprint Reports”
- Within that Wiki, add an article for each new sprint (we have them by weeks). That article (not the entire Wiki) should have the same tag as that of the sprint.
Then, the following things help further:
Firstly, if you simply search by the tag, you will find: all cases and the specific Wiki article (which even in headline view shows you the goals)
Secondly, create two filters: one filter for showing the cases of that scrum in a list view, and second filter for showing cases open/closed in a pie chart. As you go through the week, you hope to have eaten more of the pie.
The only thing that I don’t like about this is the need to modify two filters every Friday, but if that is about the pain you have on a Friday, your weekend has already begun.
Oh, and while we are on the topic, FB Wiki Editor is better than one in 7.0, but really should be versioned 0.8. It is at least 2 editions away from being something stable.
So, that is it, and I hope with these tips, you are flying through your sprints (the dog pic courtesy Dave Hamster).
March 26th, 2010
Product design and innovation
Once in a while, I do get this question: “So, what is it that you do do?”. Now, I could say something like product development, but since my Eclipse IDE stopped working back in 2007, I haven’t gotten around to fixing that (yet), that kind of answers that one. Perhaps the clearest answer is this – conceptualizing software products that I believe can help people solve their problems. We can dissect that line word by word:
- conceptualizing: I refer to it as “conceptualizing”, as the design and development is usually done by a different team.
- software products: Yeah, that is the space I am playing in, at least at the moment.
- “I believe”: Any product designed is a gamble, and it is best to acknowledge that as such, upfront.
- help people solve their problems: This is obviously at the core of building a product. The problem that the product will solve is usually the best indication of the success of this product. Is this problem worthy of solving? How much of a problem really is this problem? How many people may have this problem?
There are 3 well known rules of engagements when creating products:
- Ask the users (but sometimes not believe them): Since the products don’t exist yet, the users have some ideas, but some of them may be too specific to their unique problems. So while the users’ first few sentences are of huge value in describing the problem, detailed thesis are not. It is best to engage users in small but frequent sessions so they can react to latest version of the product. Also, this avoids the pitfall of solving a user’s specific challenge on a specific day. We want to solve REPEATING problems, not one offs.
- Not worry about the so called “competition”: This is an important concept. No matter what you come up with, people will try to box other products and label them as your competition. This is usually done with the best of intentions, in some cases just so as to explain your product. But focus on the users with problems, not other products that they could hypothetically use but are not using.
- Don’t overvalue innovation over execution: As Facebook and many other successes have shown, it is a fallacy to think that every success comes from making something new. Not necessarily true. Any new product usually has 3 kinds of features: (i) Features that are new, (ii) Features that are old, and (iii) Features that exist in a different form in other products. Counter intuitively, usually it is the last category – the features that exist in other products, but in less usable or functional form – that is the best reason for the success of the product. (Second in importance are the features that are old.)