It's been recently brought to my attention that I don't view open-source the way that many of my friends do. My attitude has always been: Here's some code that works well for what I want. If it works well for what you want, great! If not, I'm willing to make changes that improve the library; however, I'm also going to reject any code that causes the library to bloat. Lastly, the library will likely be 'done' in the next few years - at which time I expect it will be mature enough that a stable final release will be possible, or someone will (re)write a superior version. I don't expect an open-source project will ever define what I accomplish in our industry. It finally occurred to me that others don't think this way when they began telling me that they don't open-source due to -

• the code isn't mature enough
• they don't want to write documentation
• they don't want their time monopolized by feature request emails

I can understand each point of view, but events have occurred in my career that have shaped my (differing) opinion.

I still remember my first open-source project: I didn't tell a soul about it until I had used it in production for over a year and was very confident that I'd addressed the majority of common use cases. It was a .net object relational mapper called NORM, and it was released in 2005. No, you haven't ever heard of it. I polished it for months, and no one cared. After that I never waited to release anything. I now believe that it's highly unlikely that whatever I create will ever gain any traction, so I might as well get it out there, fail quickly, and move on.

No one writes documentation for themselves, they write it for people who they hope will use their software - and very few people people ever gain anything from someone else using their open-source software. That simple equation makes documentation scarce; however, scarce documentation doesn't mean you can't open-source your software, it just means adoption rates will very likely be slowed.

Two years ago I open-sourced expectations with zero documentation, and documentation stayed at zero for at least a year. In that year very few people paid any attention to expectations; however, expectations does fit a sweet spot for some people, and some adoption did occur. Eventually, new adopters began to send pull requests with documentation, and their contributions inspired me to write some documentation of my own. It can be hard to get motivated about providing documentation to theoretical adopters; however, I got my code out there and adoption began, and the motivation came along with those (no longer theoretical) adopters.

If you end up lucky enough to create a project that is widely used, there's no doubt that you'll start getting swamped with email. In the beginning I expect everyone will be overjoyed with their success, and the added workload will be no big deal. However, I imagine over time it begins to feel like a second full-time job, and for what? Developer-fame doesn't get you closer to retirement any faster than watching grass-grow. However, I don't believe that should deter you from putting your work out there. Additionally, I think GitHub has changed the game with respect to moving on. If your project is on GitHub and you decide to call it quits tonight, there will probably be plenty of forks that are more than happy to take your place.

I have no qualms with walking away from projects, as I expect that if the idea is valuable, someone else will be happy to step up and take my place; furthermore, it's more likely that several people will step up and the strongest will survive - which is best for everyone. The best example I've ever seen of this behavior was Capistrano. Jamis Buck famously walked away from Cap in 2009, yet I still know plenty of people using it today without any issue. I firmly believe that if an idea is good, it'll live on even if you've decided you're ready to do something else.

It occurs to me that I might be a bad open-source citizen - releasing way too early and walking away too early as well. If that's the case, then I expect well deserved criticism, but that's just not how I see the world at this point...
© Jay Fields - www.jayfields.com

Another beautiful rant from Uncle Bob: Here’s what an application should look like. The use cases should be the highest level and most visible architectural entities. The use cases are at the center. Always! Databases and frameworks are details! You don’t have to decide upon them up front. You can push them off until later, once you’ve got all the use cases and business rules figured out, written, and tested.

8th light must be something else.

Here's a snippet from a recent comment on a oldish blog post of mine:
"However, in this post there is one thing that touches a raw nerve. The whole point about whether the person does coding in his free time. Why would you care? In fact, the point of free / spare time is to do activities you don't do at work. Today, I've an MBA and am far removed from the tech world, but I'm involved in recruiting for consulting (the industry I work in), but I'll not hire a person who does cases during his / her spare time. I'd rather hire someone who has a life and some hobbies. Such people can be much more interesting, fun to work with, and actually more versatile at solving business problems than someone who has a unidimensional personality."
Every time someone says something like this, I'm appalled. No, really, that's the only word for it.

First, I don't understand the constant assumption that if you choose to study in your spare time, you have no life. Some of the best programmers, entrepreneurs and managers I know (some are all three) run marathons, are published authors, do underwater photography and more without ever compromising on study. Truly passionate people have several passions - and their greatest passion dictates the area in which they choose to work, but never to the complete exclusion of everything else. The stereotype of the programmer living in a basement doing nothing but write code is just that - a stereotype. People who fit the stereotype are the exception, not the norm, believe me. That said, I do wish that the manager who did nothing but study cases was also a stereotype - most professional managers that I meet last read a book during their MBA (and it was the Nirma washing powder case) and haven't been exposed to a new idea since. But I digress.

I also find the 'if you study, you have no life' argument something of a cop out. It tells me that you aren't passionate about what you do for a living - if you were, studying and getting better at what you do would be something that just happened automatically. Henry Ford created the assembly line because he constantly studied manufacturing. Sam Walton created Walmart because he spent all his time studying retail. Nobody creates anything great without expending considerable effort studying the problem and trying different solutions. We aim to write great code as one of the key parts of solving our customers problems, so yes, I prefer people that are looking to become better programmers. Such people almost always hack on personal projects in their spare time; as far as I can tell, it's the quickest way to identify the best programmers.

Second is the implication that people who are passionate about what they do and express this by working on their skills outside of work hours aren't 'versatile'. I've never figured out what the connection is here. Is it that someone who does not consciously work to improve their skills must perforce be better than someone who does because they become (magically) more versatile? The answer to 'Are you an expert in your field?' isn't 'No, but I have hobbies.'

Are you saying that if you conducted an orchestra, you'd refuse to include a musician who practiced outside of the concerts they played in? Are you saying you wouldn't consult a doctor that studied the latest advancements in medicine? What's special about programmers or managers that they're exempt from others expecting them to improve their skills? As far as I'm concerned, the important thing to remember is that even if you are an expert in your field today, you won't remain one unless you're constantly introspecting and working to improve. Your career will falter, because your peers are improving while you're standing still. This isn't rocket science - everybody wants to work with the more capable person, not the less capable one that has hobbies. In my experience though, the more capable person is usually the one with the hobbies and the less capable one is usually a couch potato in his or her spare time.

Lastly, the whole notion of how people perceive learning at work as being something that must happen during working hours strikes me as being rather odd. When you were in school and college, did you do all your studying in the classroom? No - you studied in what was, technically, your spare time. So what's the deal with expecting to learn everything you need to know during your eight hours at work? Now that's what I call unidimensional - someone whose knowledge of their domain encompasses merely what they see during work hours.

To cut a long story short: To study or not to study - the choice is yours; but don't ever fool yourself into believing that passionate people that study are in any way the poorer choice for any role. That perception is a fallacy.

Update:

Here are the links to conversations around this post on Hacker News and the Software Craftsmanship list.


If you liked this post, you could subscribe to the feed Follow @ponnappa or simply comment on this post

Valve handbook. Very cool:

http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf

I had no intention of writing about this meme because I'm biased by the fact that we're building a platform to allow programmers to teach programming, but then Jeff Atwood wrote his "Please don't learn to code" post. I'm sitting at home, grumpy because I'm ill, so this was all the excuse I needed to get this off my chest.

Frankly, I don't care if Mayor Bloomberg should learn to code, mostly because I don't live in New York. For me, what's important is the fact that he will never learn to code non-trivial programs by going about it in this manner. Much of the hype on the internet misleads people into assuming that by writing a code snippet a week, they're going to become programmers. That's like assuming if you solve a Sudoku problem once a week for a year, you will become a mathematician.

Learning programming is not easy. It's easier than many other disciplines because you can learn through experimentation, but to be a good programmer, you need to make the effort to understand how computers work.

The less you understand, the less effective you are as a programmer.

You see, any non-trivial software program depends on dozens or hundreds of abstractions. For the non-programmers reading this post, an abstraction basically hides a complex mechanism or concept behind a simple interface. A real-world example of an abstraction would be the remote control of a television - you don't need to know what goes on in the circuitry of the TV to switch channels; you know that hitting that button makes it happen, and all of the underlying complexity is "abstracted away" from you, the user. This is ok, because you are not in the business of designing and building TVs.

You can certainly write many trivial programs without looking under the hood, but for bigger pieces of software, some understanding of how all the abstractions in your system work is essential. Memory management, threading, storage and scheduling are just some of the areas one needs to be familiar with before you can understand why your program behaves in a certain way. Once you get into production software you need to understand networks, packets, routing - I could go on like this for five minutes. Without understanding all of this, the behaviour of your program is a black box to you. When something goes wrong - which it will - you will have no idea why it happened. And you will not be able to fix it.

Getting the basics sorted would easily take six to twelve months of serious study. Without this, you're just messing around doing building "Hello world" programs that provide gratification to you and little else.

Long story short, there's nothing stopping anyone from becoming a kick-ass programmer, but remember, programming isn't an exception to the 10,000 hour rule.
If you liked this post, you could subscribe to the feed Follow @ponnappa or simply comment on this post

I have been working at Microsoft for a month now. People talk about starting here and taking it all in as "drinking from the fire hose" and at first I laughed but now I know it is the case. There is nothing as overwhelming as starting a job at Microsoft. It is also overwhelmingly enjoyable.

One thing that made me take the job was this amazing female manager who interviewed me. She was inspiring and had presence, from the second she entered the room.
I never believe that an interview is about them. Do not think that the people interviewing you are there to choose you. You have to choose them back.

Being interviewed by a woman, in a company who has a woman running their Australian arm and had that before, counted a lot towards my positive view of this  company. My friend who recommended me is a female evangelist. My male friends who work there have supported me through my career.

It is true that I didn't post on International Women's Day so I'll make today my IWD. As I sit here blogging today, knowing that so  many women helped me get to where I am.

Thank you, girls. Thank you.

Efficiency arguments bore me. "Don't reinvent the wheel" and "Duplication of effort" are phrases that tell me the speaker does not understand the context of the situations in question. Notice how the solutions they propose are things like "introduce a framework", or "create a common library" or "use a standard tool"?

Stripped of their buzz-phrase finery, all I hear is: "Let's do some work, so we can avoid doing work."

If we don't trust that the people closest to the problem are looking at their options and choosing to "roll their own" because it's the most efficient solution, then we need to solve that problem, instead of trying to solve their so-called common problem with an externally imposed solution.

If you've ever spent any time learning Rails then you probably read one of the editions of Agile Web Development with Rails, and if you're like me (skeptical & pedantic) then you probably asked yourself: what the hell does Rails have to do with Agile development? At the time, I assumed that Dave and David were merely capitalizing on the buzz around Agile; however, even if that's the case, I think they did manage to highlight one of my favorite aspects to building websites with Rails: The ability to make a change, reload the page and see the results makes you a much more agile programmer - where 'agile' is defined as: Characterized by quickness, lightness, and ease of movement; nimble

It turns out, it's not very hard to get that same productivity advantage in Clojure as well. I would go so far as to say that the ability to change the server while it's running is assumed if you're using emacs+slime; however, what's not often mentioned is that it's also possible (and trivial) to reload your server code (while it's running) even if you're using IntelliJ, scripts, or anything else.

The majority of the servers I'm working on these days have some type of web UI; therefore, I tie my server side code reloading to a page load. Specifically, each time a websocket is opened the server reloads all of the namespaces that I haven't chosen to ignore. The code below can be found in pretty much every Clojure application that I work on.

(defonce ignored-namespaces (atom #{}))

(defn reload-all []
  (doseq [n (remove (comp @ignored-namespaces ns-name) (all-ns))]
    (require (ns-name n) :reload )))

Like I said, when I open a new websocket, I call (reload-all); however, the (reload-all) fn can be called on any event. When discussing this idea internally at DRW, Joe Walnes pointed out that you could also watch the file system and auto-reload on any changes. That's true, and the important take-away is that you can easily become more productive simply by finding the appropriate hook for what you're working on, and using the code above.

The ignored-namespaces are important for not reloading namespaces that don't ever need to be reloaded (user); other times you'll have a namespace that doesn't behave properly if it's reloaded (e.g. I've found a record + protocol issue in the past, so I don't dynamically reload defrecords in general).

The change-reload webpage-test loop is nice for making changes and seeing the results very quickly - and I strongly prefer it to having to stop and start servers to see new functionality.
© Jay Fields - www.jayfields.com

I tried to do A, and I really don't understand the response I got, X.  Does this make sense?

I know it should be possible to do A, but I tried it and X happened.  What sort of conditions would cause that?

I tried to do A, and X, Y, and Z happened.  X makes sense, but I don't understand Y, what's going on here?

It doesn't really matter whether you're asking about automation or any other kind of testing.  The tricky part is that before asking the question, you had better be pretty familiar with A, and you had better be able to report X, Y, and Z in a reasonable way. 

I have a corollary, and I have a (counter) example.

I have seen any number of people in the software world complain about testers who submit bad bug reports.  I'm sure it's true, I've seen the evidence, and it boggles my mind.  A good bug report will explain A and explain X, and a great bug report will phrase the issue in terms of a question. 

Not long ago I got an email from someone asking about a little script I wrote some time ago.  He asked me to give it to him.  I have not replied. I was astonished.  For one thing, a cursory google search would turn up the 30 lines of code in question.  But even worse than that:  why don't you WRITE IT YOURSELF? 

It's quite possible my script no longer works.  It's quite possible that there are better ways to accomplish what the script does than what I wrote.  But I absolutely refuse to copy'n'paste 30 lines of code in an email response.

Eric Raymond (if you don't know that name, google it) wrote an essay a long time ago How To Ask Questions The Smart Way.  I'm guessing that many readers of my blog are not familiar with it.  This is a travesty. 

NB: the last time I pointed a software tester to Raymond's essay, I was accused of misanthropy and worse.  Testing might be dead.

This is a guest post by Rusty Zarse CTO of Search Discovery, spurred by a series of email conversations that we had regarding the difficulty of finding experienced Rails talent. Rusty leads the Atlanta iOS Developers meetup and is one of the better known technologists in our city.

Where'd Every RoR Go?

“Rails is hot,” ain’t no headline today. Five years ago, Ruby on Rails was an underdog, the somebody to watch, the next big thing. It's not news that the Rails community continues evolving and growing while its members do a good job protecting the integrity and quality of the platform. Rails 4 is visible on the horizon and looks better than ever. The growth of the Rails community worldwide appears to be relentless, but there's a dark underside to that growth that does not get enough attention: In terms of sheer numbers, there just doesn't appear to be enough Rails developers to properly serve the needs of the market.

Technical organizations (particularly at the CTO and Director level that I inhabit) are now faced with a stark decision of choosing the Rails platform on its virtues or reluctantly giving the nod to another technology that carries less staffing risk.

On the face of it, people might think that this situation is good for Rails developers because it means that they continue commanding astronomical billable rates, higher quality coding practices and standards for their professional ecosystem and the aura of elite superstars. But Rails remains a community-driven platform and so it's up to the community itself to identify the needs of the market and identify what can be done for our overall growth to continue to flourish.

Attracting Rails Talent

Our core product at SearchDiscovery does things that truly push the envelope. There's a lot of work remaining to be done, but we feel that it already does what nothing else in the world can do. We owe a lot to the exceptional genius of our Hashrocket team and the wizardry of the lead developer they provided to us. During my career I've led many projects and never seen a product reach this level of complexity without falling apart due to compromises and shortcuts made along the way. I attribute our success in no small part to the principles and practices that Rails embodies. It is the motivation that I had for choosing Ruby on Rails as our web development platform to begin with and continues to provide a level of quality and productivity that I believe is unmatchable.

Our dilemma is that in over 3 months of arduous searching, we have not been able to find even a single Rubyist in Atlanta interested in joining our team. I'm not talking about having to turn down interested applicants; I'm talking about not having any interested applicants to begin with.

Now we have new products in the pipeline and our CEO is pushing to choose an alternative platform. Some of us know PHP and I personally know .NET. My experience with PHP is that its a great hacky tool to tweak wordpress and everything else just becomes spaghetti soup. Microsoft .NET is the platform of choice for developers who like to write the same oil tanker full of plumbing code over and over again just to show how great they are at doing things "better" than everyone else. Here in Atlanta, a common alternative to Rails is .NET, given the large Microsoft contingent we have in town. In my opinion, .NET doesn't deliver quickly enough and PHP inevitably becomes a maintenance nightmare.

Why on earth would we consider switching off Rails? The painful truth is that we need a team of professionals more than we need the best technology. We don't even need to hire an entire army of engineers immediately. We're specifically looking to fill at least one senior position so that this individual can cultivate Ruby on Rails talent within our walls. Our long-term goal is to become that company everyone in Atlanta wants to work at. We admire companies who posses an organic energy and self-managed excellence within their development team and we're willing to invest the capital needed to get there. I feel  that we have the professional atmosphere and culture that would be attractive to Rails professionals, but where are they?

Rails in Atlanta

Obviously, timing is everything. I've tapped the local user group community and will continue to do so, but so far have not seen much interest in the position. When I do connect with a local Atlanta Rails expert, often the professional courteousness is not reciprocated. I don't want to complain about specific people, but c'mon it just isn't necessary to be rude when someone asks if you are available. Clearly I'm trying to recruit someone, but I'm a CTO not a recruiter. Is politeness too much to ask for? Most technical people in Atlanta are nice and as helpful but there are a handful of dudes with serious reputations that apparently forget that we're all in this together. Their dismissive attitudes are toxic to non programmers who just want to run a business.

Worse, these bad attitudes get back to my bosses. I can argue all day about the gazillion benefits that using Rails brings to the table, but I can’t argue against the facts of our recruiting problem!  

A Plea to the Community

I wrote this post at Obie's request when I asked him for advice. I'd failed to consider that this is more than just my problem, more than just a hiring problem: It's a Rails community concern. The Rails platform is not bleeding edge anymore. It's proven, mature, reliable, amazing and a proper choice for just about any web development problem domain you might encounter. I don't know what the solution is, but I do know that we need to ensure that it continues to be the platform of choice for innovation.  We’re committed enough in the concept to put our money where our mouth is.

What do you think? Is this actually a community problem? Let's get a greater dialogue going.

At RiverGlide, we’re often asked to help with “Agile transformations”.

My definition1 of agile is being flexible to adapt an existing process.

That is, if your existing process looks like waterfall, you’re still agile if you introspect, retrospect and experiment to improve your process. If at the end, your process looks like waterfall, then as long as you have introspected, retrospected and experimented and found that this approach gives the best results, then your process is agile.

[1] Although this might not fit with other definitions. Your mileage may vary

I’ve been playing around with core-plot, a graphing library for MacOS/iOS, which ships with a local dotset.  A normal double click on the docset from Finder wasn’t enough to read it, after a bit of Googling the solution seems straightforward:

1. Shutdown Xcode.
2. Copy the .docset in to ~/Library/Developer/Shared/Documentation/DocSets
3. Restart Xcode.

If you want to check that Xcode has picked up the new docset then look in Xcode Preferences under Downloads.

Just a quick note to say I was interviewed for another podcast, again to talk about all-female events.  It's only a short one and there's probably not much in there that I haven't said before, either on here or in person.

From the 21st May, I'm at GOTO, both Copenhagen and Amsterdam.  I'll be talking about code & the Disruptor, thank goodness, and will be trying not to rant about the subject of women in technology.  If you see me there, come and say hello!

On Friday 25th May, after all the GOTO craziness, I'm going to repeat the Disruptor presentation in Rotterdam at 010DEV, an event rather fantastically called "The Disruptor and the Perfect Programmer", which someone on Twitter correct noted sounds like a fairy tale.

After all that, I'm hopefully going to take June off to play Diablo 3 and Prototype 2, and read the next Game of Thrones book.  All these joys I have been denying myself to make sure I get everything sorted in time for next week.

For a time, I was a coach. A personal / life / business coach. I loved the work. Well, it didn’t feel like work. It was joyful and amazing.

It was not uncommon for a client to tell me that they felt that they were not yet what / who they wanted to be. When this came up, we’d discuss the question of who or what they wanted to be. We’d create an image of that future self, including the way they’d talk, the way they’d walk, how they’d hold themselves, their posture, their gestures, the presence they’d create when they entered a room, and so on. A rich, full vision of the future self.

Powerful.

“Wow! That’s who I want to be. How do I get there?”

Sounds tricky, right? I mean, if it were easy, wouldn’t we all be powerful or leaders or loved or in the job we want or…

Here’s the technique I shared with my clients.

I get that you’re not yet that person. You have a clear picture of that version of you, who seems like a different person right now. You have a clear picture of how that person would speak, what they’d say, how they’d stand, how they’d move, and the gestures they’d use, right?

Channel that person. Don’t try to be that person. Act like that person.

What would that person say in this situation? Say that.

What would that person do in this situation? Do that.

It has been successfully demonstrated repeatedly that we can change our feelings by changing our words. We can change our behavior by choice, repeating the changes until they become our real selves.

So rather than wondering what I need to do to become the person I am visualizing, I choose to act like that person until I become that person.

Take it on like a persona, until it “takes”.

As it settles in, my feelings will change to reflect the confidence I begin to feel. The behavior will become natural and mine.

One day, I will wake up and discover that I have become the person I was visualizing.

Here’s some code that takes a block called success.

   AFJSONRequestOperation *operation = [AFJSONRequestOperation JSONRequestOperationWithRequest:request success:^(NSURLRequest *request, NSHTTPURLResponse *response, id JSON) {
        
        // city
        NSString *city = [JSON valueForKeyPath:@"location.city"];
        NSString *currentTemp = [JSON valueForKeyPath:@"current_observation.temp_c"];
        
        // create a weather object
        Weather *weather = [[Weather alloc] init];
        weather.city = city;
        weather.currentTemperature = [currentTemp intValue];

        // notify!
        NSDictionary *dictionaryWithWeather = 
        [NSDictionary dictionaryWithObject:weather forKey:WEATHER_KEY];
        [[NSNotificationCenter defaultCenter] postNotificationName:WEATHER_KEY 
object:self userInfo:dictionaryWithWeather]; 
        
    } ...

Cool. But what if I want to pull out that ‘success’ code out into a variable and pass it to the calling method. Here’s what it looks like.

First define a typedef for the block:

typedef void (^success)(NSURLRequest *request, NSHTTPURLResponse *response, id JSON);

You can figure out the typedef method signature by looking at the underlying code, and then just sticking the word typdef in front of it. Note ‘success’ is the name of typdef here.

Then define a variable for the block:

    success requestSuccess;

Nothing magical. But I want you to see what assigning a variable to a block looks like. It looks like any other variable assignment.

Then instantiate your method and define the contents of the block.

    requestSuccess = ^(NSURLRequest *request, NSHTTPURLResponse *response, id JSON) {
        // city
        NSString *city = [JSON valueForKeyPath:@"location.city"];
        NSString *currentTemp = [JSON valueForKeyPath:@"current_observation.temp_c"];
        
        // create a weather object
        Weather *weather = [[Weather alloc] init];
        weather.city = city;
        weather.currentTemperature = [currentTemp intValue];

        // notify!
        NSDictionary *dictionaryWithWeather = 
        [NSDictionary dictionaryWithObject:weather forKey:WEATHER_KEY];
        [[NSNotificationCenter defaultCenter] postNotificationName:WEATHER_KEY 
object:self userInfo:dictionaryWithWeather];        
    };

Then replace the code you pulled out with the call to the block variable:

    AFJSONRequestOperation *operation = [AFJSONRequestOperation JSONRequestOperationWithRequest:request success:^(NSURLRequest *request, NSHTTPURLResponse *response, id JSON) {
        
        requestSuccess(request, response, JSON);
        
    } 

Voila! Cleaner more readable code.

Filed under: iOS Tagged: blocks, ios, objective c

I've been rereading Zen & the Art of Motorcycle Maintenance. This quote really struck me:

"You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it’s going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kinds of dogmas or goals, it’s always because these dogmas or goals are in doubt." ~ Pirsig, Robert M. (2009-04-10). Zen and the Art of Motorcycle Maintenance (p. 140).

Made me think of all the zealotry accusations levied at Extreme Programming practitioners about 10 years back... still seen in reaction to some of the more ardent claims of the primacy of TDD even today.

No conclusions, just suspect I will see the next fanatic a little differently next time I encounter one.

Remember the SAT test and their ridiculous analogy questions? “Apple : Banana as Steak : ???”, where you have to figure out the relationship between the first pair in order to guess what the relationship in the second pair should be? (Of course, the SAT guys give you a multiple-choice answer, whereas I’m leaving it open to your interpretation.)

What triggers today’s blog post is this article that showed up in GeekWire, about how Firefox is accusing Microsoft of anti-competitive behaviors by claiming IE will have an unfair advantage on their new ARM-based machines.

Anderson says the situation has antitrust implications. Microsoft has agreed to abide by a set of principles to maintain a level playing field on Windows for competitors despite the expiration of its consent decree with the U.S. Justice Department.

OK, wait a second here. Last time I checked, there’s another operating system out there that completely and entirely prevents any kind of web browser from being deployed on it, which strikes me as grossly anticompetitive, and yet Mozilla chooses to fire their guns at Microsoft, who is attempting to take a shot at the ARM market?

Seems to me like somebody’s either not getting the point of “anticompetitive”, or else they’re just taking a potshot at the company that everybody loves to hate because it’s an easy shot. If Mozilla is really serious about anticompetitive concerns, they will ask DOJ to investigate Apple’s iOS (that owns, what, 2500% of the tablet market) and AppStore, not Microsoft IE on a market that doesn’t event exist yet.

Otherwise, I call bullshit.

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.

I've lived in Bangalore since I was three - we moved here in 1987 after my father retired from the public sector that year. Bangalore, then, was known as a retirement city, famed for its pleasant weather and abundant greenery. The Indian economy was still closed, most of the jobs were in the public sector and salaries were low. Top executives in the public sector earned less than Rs. 60,000 a year - my father retired as the General Manager of United India Insurance, giving me a reference point. At an exchange rate of about fourteen rupees to the dollar, this amounted to around 4200 US dollars a year, give or take. Somewhere around this time was when Bangalore started to be called the "Silicon Valley of India" by the local media.

1997

Ten years on and six years into the post-liberalisation economy, Bangalore was already starting to become a software hub. I remember my cousin doing a course in Java and joining Wipro, making him one of the lucky few to have a well paying job at a respected firm. At this point, Texas Instruments had been in Bangalore for twelve years and Infosys for fourteen. Wipro had diversified from vegetable oil into IT a full seventeen years earlier. Younger upstarts like MphasiS hadn't been founded yet. The average software engineer earned about Rs. 100,000 a year right out of college which at 1997 exchange rates was around 2800 dollars a year. Senior executives in the private sector were taking home heady sums like fifteen lakhs (1 lakh == 100,000) a year if memory serves.

2007

Twenty years on, it's 2007. This was the year Flipkart.com was founded by a couple of ex-Amazon engineers. I'm twenty three years old and working at ThoughtWorks while also (with my employer's permission) moonlighting at my first start-up, InActiv Labs, where we're frantically trying to raise money. Our first offering, a SMS based personal accounting service had tanked the previous year, but our group messaging service, Activ Mobs, had gone viral. Serving the 60,000 users we accumulated in the two months after launch was costing us about three thousand rupees with spikes to six thousand rupees - every day. We were basically spending 60% of our combined founders incomes from our day jobs just paying for text messages and the numbers were rising rapidly. Raising funding was absolutely critical. Several of the bigger VCs were already in India back then, and we pitched to all of them, but for better or worse, failed to raise money. A year passed in this manner, with the service limping along. By mid-2008, we'd decided that we were going to pour our combined life savings of about five lakhs (INR 500,000) into the business in a last ditch attempt to save it.

One month later, my mother was diagnosed with a leiomyosarcoma. After that, there was no question of spending my savings - every paisa had to be saved against the possibility of our life insurance cover running out. For twelve months I hoarded money and liquidated all my investments against a rainy day. Then, through sheer good fortune, my father's forty year career in public sector insurance paid off - a new government scheme was approved which allowed retired senior executives and their families nearly infinite health cover. We could finally afford to have my mother stay in a bigger, better hospital room when she went in for her chemo. Our personal financial situation no longer impacted her treatment. My relief was immense, but it would be another six months before I even thought about starting up again.

I tell this story only to illustrate out what is perhaps obvious: That life is uncertain and when things go wrong, entrepreneurs running bootstrapped businesses are often forced to choose between loved ones and their venture, mostly for financial reasons.

2012

So on to the present, twenty five years after I moved to Bangalore. The top Indian outsourced services firms have all exceeded 100,000 employees. The total number of truly successful Indian internet startups is under ten, and every single one of them replicates a validated business model imported from the first world. Funding is easier to come by, but Bangalore is still an arid desert when compared with the Valley. Basically, the Indian tech startup ecosystem is still a tiny tiny thing in much need of nurturing.

From an economic perspective, salaries are rising at 15% annually, with most college grads starting at one of the big services companies with around 3 lakh rupees a year (or 6000 dollars at the current exchange rate). Most mechanical engineering, civil engineering, industrial engineering and chemical engineering graduates wind up at one of the large services firms where they learn to how to write software. Their engineering degrees are largely wasted; the more driven among them embrace this reality and do an MBA in a year or two and stop writing code in favour of a career in management.

CS grads that are above average start work at about five lakhs a year, and the really good ones can start with ten lakhs or more, though there are just a handful of openings at this salary level. Salaries for roles that require serious programming skills are going through the roof, but it's still incredibly hard sifting through the chaff to find people qualified for the role. Amazon, Zynga and other product companies that have development arms in Bangalore still find talent inexpensive relative to the six figure salaries they pay in the US and are happy to pay very very well, especially in contrast with the large services firms. Most capable programmers now naturally gravitate toward established product firms, where it's not unusual for someone with five years of experience to earn twenty lakhs a year (40,000 dollars at current conversion rates). You'll notice that while the India-US PPP ratio is 1:5, software salaries are actually at about 1:3.

No virtuous circle

This now brings me back to the title of this post, the "virtuous circle." In the valley, failing at a startup for the right reasons earns respect and makes people take you more seriously. It also makes it more likely that you'll raise funding in the future. Failure benefits you in visible ways, creating a positive feedback loop that works to increase your opportunities. In the valley, you're surrounded by people that made serious money by founding or working at startups. It's obviously a viable way to earn a living; sure, starting a Facebook or a Google is like winning the lottery, but even without you can earn a very respectable income from your salary and stock options. Startup meet-ups happen every other week, with a hundred people or more in attendance at every one.

In contrast, I don't know anybody in my personal network in Bangalore that's made significant money from a tech startup. I know of a handful of people, but have never met them. Start up meetings are rare, with a handful of people showing up. Most of the time in the meeting is spent bike-shedding. If you're lucky, you'll meet one person running their own business at such a meeting - the rest are all aspiring entrepreneurs.

Negative feedback loops

In India, failing at a startup means you go back to a regular day job for a couple of years to refill your bank account. Your failures create no additional value, because the learning from them aren't useful to the current ecosystem. You'll certainly get a regular job based off past experience, but don't expect the fact that you started a company to count for much. We don't have two generations of successful technology entrepreneurs ready to give a leg up to the current crop by mentoring them. We don't have the early stage investment ecosystem to infuse money into promising businesses. Most fundamentally, we don't have a society that values risk takers, because in an economy like India's, risk takers crash and burn and may well take their families with them. Everyone, from your parents to your siblings to your in-laws will call you crazy for giving up that cushy job at a top product firm. And you know what? They're likely right.

Here, doing a product startup only makes financial sense if you're in your early twenties, intend to remain single or have a substantial inheritance. As you get older, you absolutely need a steady, significant income because unlike the first world, you're paying for your kids education from the age of three and up. You're likely to also be supporting your parents by the time you're is your early forties. Education and healthcare are, as I'm sure you know, expensive.

This means that you have a narrow window early on to successfully do a product start up. Missing that window means the realities of life will force you into a regular job. Even if you tenaciously hang on, you're doing so knowing that you're forcing your family to compromise on their lifestyle to allow you to pursue your dreams.

Added to this is social pressure from older generations, many of whom lived through the Licence Raj and struggled to find any job, leave alone start something of their own. As a friend of mine pointed out so succinctly, unless you're fabulously, visibly successful, you're always the chap running that "computer angadi" ("computer shop" in Kannada). To most of our grandparents and parents, quitting a steady job is tantamount to social and financial suicide.

Quitting a steady job at a big-brand firm to join a smaller company is not as bad, because, you know, you're still an employee (which is a good thing), but they'll still call you stupid for giving up the brand. "Your son didn't get job in Infosys-aa?" was a question my mother had to field from all quarters when I joined first started working.

Doing it right means playing safe

In India, the deck is both socially and economically stacked against the entrepreneur. The question, then, is how do we change the odds and make life a little easier for ourselves?

Let me start by outlining the constraints that we need to satisfy:
1) You need market-equivalent income to support those who depend on you.
2) Your business needs to be stable so you're better able to hire.
3) Your business needs to be very profitable so you can pay well, because you're looking to hire top talent, you're competing with Amazon and Zynga, not Infosys.

You'll notice that there's a conflict inherent in (2) and (3). Stable business models grow slowly and usually aren't very profitable. Since you clearly can't do both, you need to pick one. Most entrepreneurs in Silicon valley shoot for (3) and trust in their ability to raise money and bring in senior advisors to introduce some stability. We don't have that luxury, so we need to shoot for (2) first, and then figure out (3).

Satisfying these three constraints led us to the business model that C42 Engineering currently follows. Here's our reasoning:
1) We solved the market equivalent income problem by starting out as a boutique Ruby consultancy. We get good rates, which means we can pay fairly well.
2) A services business run right is very stable and predictable. It is also an excellent source of challenging engineering projects, making it even more attractive to programmers which in turn makes it easier to hire.
3) Channel 100% of services profits into a product arm with multiple products if possible. Iterate. Fail fast. Ship. Rinse. Repeat.

C42 Labs, our product arm that was responsible for RubyMonk, has an annual budget of 60,000 dollars, a sum we're likely to double in the coming year. This is about 4.5 times my annual salary when I quit to start C42 Engineering two years ago, so it's clearly an improvement over my ability to fund such a project back then. It not be much when compared to the millions that startups in the Valley routinely raise, but it's a solid, dependable sum produced in a sustainable manner. We're also creating a brilliant team of engineers in the process of growing the consulting business and are getting to work on some amazing projects for  interesting, successful companies in the process.

We have big dreams for RubyMonk and the learning space. The ultimate goal of the Young Lady's Illustrated Primer beckons. But the best ideas sometimes fail, and if, to our ill fortune RubyMonk is one of them, we'll still be back at work on the next business plan in our pipeline the very next day. No downtime, no salary cuts, no layoffs, no bad mojo.

Conclusion

If you've been involved in the Bangalore start up scene, you know that services start-ups are often looked down upon as being "impure." When I was a working on Activ Mobs, I too was of this opinion and strongly felt I'd never like to do a services business. This harsh perception is driven by the fact that many product startups start doing a little consulting on the side to ease cashflow and before you know it, they've become full fledged services firms. The comfort that a steady stream of revenue offers is extremely attractive after you've scrimped and compromised for a couple of years. There's a second, more valid reason for such critical view of services - every new business you add will dilute your focus. When you have both consulting and product, you focus is halved. This is a risk any diversified business faces, and frankly, there's no good answer to this besides "be more disciplined."

What I do have to say is this: Deal with the risk. Define it. Work it into your business model. The solution to a paucity of early stage funding and expensive talent isn't hoping that things will get better, and that your business will survive until then. Figure out how to make a small amount of money early, and in a reliable manner. Then re-invest and diversify. You'll grow more slowly and take longer to become massively successful, but you're now much more likely to make it to the end of the road.

Don't worry about local "wisdom" -  just do the sensible thing. This could mean you start with consulting like us, or simply bootstrapping in you spare time like my friend Akshat's doing until you get to sustainable revenue, then quit to run the business full time.

But whatever happens, don't let the naysayers stop you from starting up. Just remember that you must be pragmatic about how you go about it, because even though we wish it were more similar, Bangalore isn't quite Silicon Valley yet.


If you liked this post, you could subscribe to the feed Follow @ponnappa !function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs"); join the conversation on HackerStreet or simply comment on this post

My recent entry on Aligning Business & Programmer Goals led to an email conversation that I thought might be worth sharing.

From A. Nonymous: I have an issue with tying bonuses to performance due to, basically, performance being out of the programmer's hands. Where I'm working right now developers are treated as code monkeys: We're there to implement features the business people dream up, and nothing more. How could I provide more value when I work in an environment where

• The visual design phase has already happened (no pushback on any design elements taken seriously)
• The business development phase has already happened (i.e. the business decides to create a new service tells it's code monkeys: "we need feature x, y, and z")
• The individual projects we're working on is out of our control.

I can't figure out how to tie what I do to business value in the short term (or even in the year-long-term), because I don't have the autonomy to work on things that I think would benefit the business. I'm forced to do the work that someone else assigns me. Are the new features/bug fixes creating value? Definitely. How much value? Not a clue. How can the value I bring be measured? The only metric I'm seeing is "ease of implementing the next new feature", but the next feature that touches the code I wrote probably won't be developed for months, if not years.

So, it doesn't seem justified to assign me a bonus based on the value that features create, when I have no control over the features.My response: Given your context, I wouldn't want a bonus either. I imagine that many people are in the same situation... probably most people.

2 notes-

• The blog entry isn't solely about bonuses, the ending is all about a visible P&L and nothing about a bonus. I hope people don't completely miss that point.
• While your position is status quo, I think we should strive to do better as an industry. I don't think it's healthy that we (programmers in general, not necessarily you or me) work for organizations where we know little about the business, don't trust our business counterparts, and are not trusted by our business counterparts. Programmers are often ruthless about measurement and improvement, and wasting that effort on resume driven development or process tweaks is bad for our businesses and our reputations.

It's easy for me to say that the good programmers should quit companies that don't expose a P&L and don't empower their programmers, but I know that personal situations can limit people's choices. At the same time, I feel good about continuing to write about the path that I take, which includes quitting companies that I don't feel are aligned. Even if my ideas can't help you at this point; hopefully, something will come of them in the future. A. Nonymous followed up with:I totally get the visible P&L part and agree with you on it. Having more visibility into the inner workings of the business can only help focus effort where it's important. Not every business leader feels that way, unfortunately. I'm currently fighting with my boss about a similar issue. I alluded to it before, but he wants to follow what many consultancies are now calling "Agile":

• analyst meets with business team
• analyst comes up with features
• qa writes acceptance test for features
• developer receives/estimates/completes features

At no point in this process does the developer have any contact with the business team.

Do you have any idea how I'd go about convincing upper management that sharing the P&L would be a good idea? And, my final response: I've never seen studies on the impact of sharing the P&L. Most of the discussion around this stuff is still in it's infancy as far as I can tell. Brian Goetz has been talking about 'language & framework introduction' for awhile, but I've never heard it combined with P&L.

I would attack your situation in one of the two following ways-

• Fully support your boss' plan, but request to be put on a 'research' or 'experimental' team where you interact directly with the business on a new product (assuming that's possible). I've done this successfully. The rest of IT followed the traditional approach that your boss is proposing, but I broke off with 1 PM and we worked directly with the business on technology for new business lines. I never got to see P&L (though, I never asked), but I would get requirements and deliver features on demand and we ended up constantly impressing the business. e.g. "business: How quickly can you deliver this? (I start thinking of my estimate) business: August? me: (shocked, it was March) I was thinking in the next 2 weeks. -- that conversation actually happened, I'll never forget it. If you get this approved, your boss still gets to do what he wants, and you get to try to do better. If you succeed, he can take the credit for approving the experiment - win/win.
• Assuming you cannot find a way to interact with the business, focus all your efforts on reducing the delivery cycle. If he's going to force the team to be basically skilled labor, you need to deliver at a rapid enough pace that you fail quickly and pivot toward profitable business goals. You build, they point you in a better direction, you build, they point you in a better direction, on and on. Your 'interaction' with the business is delivering them software, and you will benefit from doing that as often as possible. So, focus on things like choosing the best tools for the job, getting the build time down, reducing the test running time, etc, etc. Anything that's slowing you down from delivering faster, it's in your best interest to remove that, so you can get the business feedback as fast as possible. Even if your boss forced you to only do a roll-out monthly (or worse), the more you have to roll-out, the more feedback you'll get - so removing any thing that takes your time and isn't contributing to feature delivery. Dan Bodart is doing interesting stuff with build times and you should be able to find plenty of advice on speeding up tests - attack that stuff so you deliver as much to the business as possible.

While A. Nonymous may never get to see the P&L, and may never be in a situation where we would want a bonus - there are steps that can be taken to align the business & the programmers.
© Jay Fields - www.jayfields.com

Keif Morris thoughtfully compares/contrasts Agile to Continuous Delivery (CD).

Of course the answer to the question posed in the post title is Yes, Continuous Delivery is agile. Very agile, in fact.

Keif raises several concerns traditional Agile has with Continuous Delivery. I admit to being from the old school, XP, and am a little nervous around CD. But I embrace its spirit.

With Agile leaving small release messes to clean up each iteration, or for Waterfall one giant mess to clean up in the release phase, is bad for the nerves too. At least CD picks up after itself in an ongoing basis.

As a daily Java programmer Maven makes a hash of this as Keif points out. But as with many things related to Maven, you gain a few pains and lose several others for net betterment. How does CD treat the snapshot ailment?