Category Archives: Featured Articles

Why Writing Software Is Like Engineering

Posted on by
6

How would you classify writing software? Is it science (as in computer science), a form of art (as in code is poetry or prose) or an engineering discipline? Terence Parr, a professor of computer science at the University of San Francisco, recently wrote about why writing software is not like engineering. Terence concludes that writing software is more an art than an engineering discipline:

Writing software is most similar to writing fiction novels. Writing novels is also an act of creation in an unconstrained and ethereal medium with few well-established construction rules.

I find this notion to be a fallacy, because writing software can be looked as a form of art, but it is largely driven by engineering. Programming can be called a craft or an art-form, but the software itself is not. My biggest argument in this context is regarding automation. Engineering primarily promotes automation of tasks. Most software is written to automate manual or semi-manual processes and enforce computational validations. However, we cannot automate art. A painting won’t automatically self-render itself into a 3D landscape. Nor would the premise of a fiction novel evolve or extend on its own, like refactored source code or OOP libraries can allow for in software.

It has become quite clear in the software world that a big design up-front doesn’t work. Engineering can solve this problem through iterative design and development. Art, on the other hand, cannot be progressive by its very nature. The final result of art is static, albeit beautiful or enjoyable.

Recently I heard Neal Ford talk about Emergent Design during a brown bag session at work. Neal is an author, a speaker and a Software Architect at ThoughtWorks. In his talk, Neal questioned the nature of code? What is software code? I think it’s a subtle yet very important construct in the understanding of software engineering.

A conventional engineer’s output, be it mechanical, aeronautical or any other branch, is the design or the blueprint. The engineer provides the very basis of objects architecture and its inner-workings. But what is the output of a software engineer? Yes, our lot designs architectures too and we also document the inner-workings (as much as some of us hate to). But the primary output of a software engineer is — the code. Hence, software code is the core output of a type of engineering, not a type of art.

To further draw the “art of engineering”, I’ll leave you with an interesting anecdote to ponder on:

Warning! If you still enjoy playing PacMan, don’t read the next paragraphs—they will ruin it forever for you. Sometimes knowledge comes with a price.

Consider the PacMan console game. When it came out in the 1970s, it had less computational ability than a cheap cell phone of today. Yet, it had to solve a really difficult math problem: how do you get the ghosts to chase PacMan through the maze? That is to say: what is the shortest distance to a moving target through a maze? That’s a big problem, especially if you have very little memory or processor power to work with. So the developers of PacMan didn’t solve that problem, they used the anti-object approach and built the intelligence into the maze itself.

The maze in PacMan acts like an automata (like in Conway’s Game of Life). Each cell has simple rules associated with it, and the cells executed one at a time, starting at the upper left and proceeding to the lower right. Each cell remembers a value of “PacMan smell.” When PacMan sits on a cell, it has maximum PacMan smell. If he had just vacated the cell, it has maximum PacMan smell –1. The smell degrades for a few more turns, then disappears. The ghosts can then be dumb: they just sniff for PacMan smell, and any time they encounter it, they go to the cell that has a stronger smell.

The “obvious” solution to the problem builds intelligence into the ghosts. Yet, the much simpler solution builds the intelligence into the maze. That is the anti-object approach: flip the computational foreground and background. Don’t fall into the trap of thinking that “traditional” modeling is always the correct solution. Perhaps a particular problem is more easily solved in another language entirely.

Excerpt from the The Productive Programmer by Neal Ford. Art titled ‘Pacman Apocalypse‘ by Lawrence Yang.

The Lean Wizard of Oz

Posted on by
2

Recently I read about the yet unbuilt 2011 Ford Fiesta that attracted more than a thousand online pre-orders within the first 6 days of the launch of its reservation program. It made me wonder not only about the marketing hype associated with such campaigns, but also about the fact that pre-orders from such campaigns help dealers gauge interest in the vehicle and what accessories consumers find most appealing.

I found it interesting that the same thought can be applied in the context of technology startups. Pre-release expressions of interest can immensely help Lean Startups gauge interest in the (yet unbuilt) product and what features consumers may find most appealing. It can also help startups ascertain the actual scope, perspective demand and real-world audience of the product, all of which are very important factors for effective monetization. After all, the first goal of a startup is to find those first 50 paying customers.

A big part of the problem is that no one knows what will work with the consumers and what won’t. No amount of market research, case studies or investment will ever substitute a real-world trial. So you start with a bare bones product that requires minimum efforts to build & release for a “preview product”, and hence reduce the time to market.

Building this “preview product”, or a Minimum Viable Product (MVP) as Eric Ries likes to call it, is essentially based on minimizing total time through the Lean Startup feedback loop:

Bootstrapping, rapid prototyping, customer driven development, iterative improvement, eliminating waste (muda), unit testing and continuous deployment are all essential components for building a MVP. Much of this paradigm is also derived from the Toyota Production System.

For example, having a paid account availability notification in your application is a tiny yet nifty approach to a MVP. You build a smaller product, or rather, you build a single feature. You incrementally improve it based on early feedback from interested users. And during this lean startup loop, you measure the actual value of the product by inviting users to pre-order your lean product.

In the field of human-computer interaction, a Wizard of Oz experiment is a research experiment in which subjects interact with a computer system that subjects believe to be autonomous, but which is actually being operated or partially operated by an unseen human being. A related true story I read about an ad-hoc approach, similar to what an MVP can often employ, goes like this:

There was a guy who wanted to sell cars online. But it was a huge system to write from end-to-end, and moreover he didn’t know if it would work or not. So he made a simple website with basic content and forms etc., but he processed the entire back-end work by hand. There was no real automated backend, but the customers got the impression that the entire thing is pretty much automated. This experiment provided him the feedback he needed for expanding his business processes and automating only the essential components.

The best way to predict the future is to invent it.

Things I Learnt This Year

Posted on by
Reply

Another year has nearly come to an end. A new decade is set to begin. It’s amazing how time just whisks away.

What’s also amazing is how much we can learn about ourself in time just by paying a little more attention to that sound in our head. After a year of pondering and progress, mistakes and accomplishments, I felt that I should share what I really learnt this year:

1. Just do it, and more importantly, do it fucking now! Create stuff that excites you. Do stuff that scares you. And, if you think you haven’t found your passion…

2. …Procrastinate. It ain’t that bad, as long as you have a desire to start somewhere. Most people never follow their dreams because they are shit scared to open their eyes. Start small, grow organically. The key is to start. Start!

3. Never argue with a fool. They will drag you down to their level, and then beat you with experience. Same goes for pseudo-intellects and pedants.

4. Health is wealth. I quit smoking for good this year. Took up swimming instead (after a halt of around 10 years). I’m nearing a kilometer of a swim daily, but what’s significant is that mentally and physically I feel rejuvenated.

5. Have positive people around you. I don’t think that people are inherently “bad”, but some people have a tendency to measuredly create naive obstacles to restrain you from doing what they couldn’t or can’t do. If you fail in your repeated efforts to make such people understand the reality, then at-least don’t react negatively yourself. One persons oasis is another persons reality.

6. Wife is always right. But that doesn’t stop me from doing what I want anyway, or so says the wifey.

7. If you are wrong, say sorry. If you are right, shut up.

8. Never do anything for money alone. Do it for a reason you believe in. Do it for your passion. Relatively, don’t be a miser but be frugal.

9. If something doesn’t excite you (makes you say HELL YEAH), then don’t do it. Family commitments are exempted.

10. The most important things in life are not things. An African saying suggests: “If you want to walk quick, walk alone. But if you want to walk far, walk together.”

11. Let bygones be bygones. The only way is forward, so move on. If others want to constantly whine on past grievances, then let them do so. Eventually, they’ll see the bigger picture.

12. The most effective productivity technique that works for me is to just have one goal in a day. If you happen to complete it, then have a second smaller goal, but never have more than one goal a day to start with and more than two goals to end with.

13. Make the World a better place. Again, this doesn’t have to be overwhelming. Don’t expect to change the World over-night. Reduce wastage. Help begins at home and neighbourhood. Start small with Kiva and World Vision. Giving is a good criterion of a person’s mental health. Generous people are rarely mentally-ill.

14. Not everybody agrees to the same things as you do. One must always respect other opinions (so please excuse my rant if you don’t really relate to much of it). Great things happen when people share their opinions, discuss them rationally keeping the larger goal in mind, and reach a simple solution. An interesting thing I took from one of my company meetings was that to make things happen (in an organization or with-in a group of people in general) you need 100% commitment but only 80% agreement.

15. Thank people.

Kudos to some really smart people like Paul Graham, Derek Sivers and many TED speakers who inspired me to prune and spruce my thoughts, and put it all to action in my everyday life.

May the New Year 2010 bring you happiness and good health. Merry Christmas.