Do it the right way vs. do it the fastest way

When I discuss features with engineers, I often get questions like this:

• Shouldn't we do it the right way?
• Are we creating too much technical debt to get this feature by the end of the month?
• Instead of doing it in a quick-and-dirty way, let's do _____.
• If there were no time pressure, we could have designed it in the right way.

These are questions that I would call design-and-speed trade-off questions.  These questions assume one thing.  The assumption is that we have to make trade-off between well designed feature and time-to-market.

Useful API design best practice

I've been thinking a lot about API.  API is at the intersection of SaaS, consumerization of IT and applications.  As more software moves to services on the cloud, it's becoming increasingly important to interface with the hosted services.  

Analogy that I have in mind is Lego blocks.  Just as Lego blocks can be stacked to create interesting things, APIs can be chained together or nested to create interesting applications.  littleBits is a good example of mixing these two metaphors into actual product.

While researching to get quickly up to speed with the best design practice for REST API, I found the Web API Design PDF written by Brian Mulloy to be very valuable.  Mulloy shares his practical recommendation of how to design Web API.  They are immediately actionable, and makes sense overall.

Practical guide to designing easy to use Web API
by Brian Mulloy can be downloaded from this link.
Image Source: http://www.apibook.com/

Good API should make it easy to develop with API reference guide.  Great API should make the API intuitive enough so that developers can browse the guide once and start using it.

Kenneth Reitz: APIs for human

Kenneth Reitz is the author of open source project called Requests: HTTP for Humans in Python.  He has been advocating about writing minimalistic README-driven API built for human.

His main thesis is that all software projects, even if internal, should be treated as open source projects with rich documentation and clear separation from the outside layers.  In order to make every module separate, each implementation should start with clear definition of what problem it is solving.  It also forces programmers to think about how it should interface with customers, including developers in case of API.  Interfaces should be minimal, lack of clutters hiding unnecessary details.  Often these details are the results of closely modeling the implementation layers instead of focusing on usability of interface.

Trying my first Github example: Crumble

1. Welcome to Future of Social Network! Click to continue.
2. You will find daily posts about social network, product management and start-ups.
3. If you want to connect, follow me on Twitter: jaeho9kim
   Thank you!

I've been seeing many Github projects from the sideline. Not having coded for considerable time, I did not have context to jump in and try Github project myself. That's been true until today.

I saw a nifty tool called Crumble. It's flexible tooltip that can guide users through sequence of steps. I thought it might be interesting to test it out since it would be useful to guide visitors through my blog.

The result is what you are seeing on this blog entry. I thought I wanted to share the cookbook style how-to for non-technical bloggers.

Why I miss my coding days

These days I often miss my coding days.  I miss the joy of putting things together and running it.  Building something with your own hands and seeing it taking a life of its own are very rewarding.  There is enormous satisfaction in seeing what you built is used by people.  It's something that you are not going to be able to describe to someone who has never coded.

Now that I have made transition to Product Management team, I rarely think about coding as rewarding and fun process.  Rather as business unit I think of coding as something to get through.  An obligatory time that you have to spend with developers to make sure the core requirements are met, and user experience stays as originally designed.  Development time is considered as long pole in time-to-market that needs to be crunched up to get to the market faster.  Business owners are incentivized to cut down the development time.