Monkey Opus

Snooty Monkey: Andrew's Perspective

Fri, 07 Oct 2011 17:06:00 -0400

Guest post by Andrew, one of the Snooty Monkeys.

I met Sean the same year that Snooty Monkey was started. At the time, I was working on a digital textbook application called ezLearnz, while working at a day job that had nothing to do with software. Sean was also working on an education app called Live Syllabus, while working a day job at IBM. We saw the possibility of a 1 + 1 = 3 situation… known as a synergistic relationship in the corporate world we were working in at the time.

Sean and I met regularly on Saturday mornings for more than a year. During this time, Sean mentored my process of becoming a software developer and we discussed educational topics, including an idea very similar to what is now P2PU. We realized we were both passionate about products that simplify and facilitate education and learning. In the end, we did not continue to pursue either of our education apps; we realized the education landscape was changing too rapidly, and what was missing from existing products was a revolutionary user interface that would radically improve users’ learning experience. During this time, I started getting interested in self-improvement apart from our discussions on the subject.

A year later, I started contracting for SnootyMonkey. Our discussions on education continued, but at this point broadened to self-improvement, philosophy, maximizing global happiness, and other interesting thoughts.

Recently I’ve become interested in the softer skills of web app development, particularly marketing. I like the idea of becoming a well-rounded web app generalist… being able to not only create an awesome app, but find people willing to pay for it. Luckily, Snooty Monkey happens to be in need of a suitably Snooty (yet open, transparent, and ethical) Marketer. And applying Snooty Monkey’s new tagline, “Simple Self-Improvement for a Complex World” to my own career, while improving Snooty Monkey, is just so deliciously recursive. Stay tuned for more Simian Snootiness as I work to figure out ethical web marketing!

A New Direction for Monkey Opus

Sun, 02 Oct 2011 18:35:47 -0400

The Snooty Monkey tagline is a common household phrase of course. But just in case anyone reading this is a recent immigrant from Papa New Guinea, or just concluded a multi-year NASA space travel deprivation experiment, the tagline is, “Simple Software for a Complex World”.

As of this moment, Snooty Monkey has a new tagline, “Simple Self-Improvement for a Complex World”. Why the new tag line? The old tagline reflected a clear mission in 2008, let me take my skills as a “software product person” and build a self-supporting consultancy, lest my family starve to death. The new tagline reflects an aspirational change here at the end of 2011, and it better fits the broader original goal of Snooty Monkey, which was to create a bootstrapped software company.

This brings me to the actual topic of this blog post, changes in Monkey Opus (which happens to be the very blog you are reading). In the past Monkey Opus has not been terribly focused. There has been a mix of entrepreneurship, product management, and technology topics. Moving forward, the focus will narrow. It’s not that entrepreneurship, product management, and technology topics will never be discussed here. I certainly won’t be able to always resist that temptation, but the major focus of Monkey Opus is now self-improvement.

Why self-improvement? Because it’s what Snooty Monkey is all about as a software company. We are all monkeys. This life of ours is our opus. Let’s be snooty about it and make it a good one!

Snooty Monkey: Lessons Learned

Tue, 27 Sep 2011 17:54:00 -0400

Snooty Monkey was started in 2008 as an experiment. The focus of the experiment? Can a CTO / Lead Developer / Product Manager type (that’s me by the way) create a hybrid micro-ISV / consultancy company? One that purposely stays small (just me? me and 2?), while serving a niche client base (bootstrapped entrepreneurs) with a niche service (temporary technical co-founder). Can doing this afford me the time to experiment with software products of my own without the traditional startup pressure that each one be a hit or the whole company fails?

Unlike a good experiment, where things are tested one at a time and variables are controlled, by necessity this experiment had lots of variables and was chaotic at times. The grand experiment is far from over, in many ways it’s just begun, but some of these experiments have now run their course, their questions have been answered and the results are ready for review and confirmation by the rest of the scientific community. It’s time to refocus the lab on new questions.

So, what has been tested so far with Snooty Monkey? What were the hypotheses? And what can now be concluded?

Experiment: Can I support my family without a “job”?
Hypothesis: Yes.
Conclusion: Yes. I’ve worked for myself since early 2009. I have yet to take the plunge and hire an employee, but Snooty Monkey is the main source of income for a few contractors (I call them friends though).

Experiment: Is there a market for a freelance “temporary: technical co-founder / CTO / lead developer / product manager” in the bootstrapped entrepreneur community?
Hypothesis: Yes.
Conclusion: I can say in no uncertain terms that many non-technical founders of bootstrapped startups will be willing to partner for some or all of the technical aspects of their business so they can focus on what they do best, eventually replacing Snooty Monkey with their own technical team when the business finds product/market fit and needs to scale. If you have the skills, drive, maturity and experience to make a good technical co-founder, there is a market for you services for cash rather than equity. In these 3 years, about 80% of the work and about 90% of the revenue for Snooty Monkey has more or less fit the experimental description. At times I’ve done work for big companies (mostly sub-contracted through interactive marketing firms) and for venture-funded startups, and almost without fail, this work has been less rewarding and fulfilling for me and less successful for the company. At the end of the day, I’m a technical entrepreneur. If I’m doing something else for you, you’re probably not getting as much bang for your buck as you should and I’m probably not having as much fun as I should.

Experiment: Can I pick and chose the projects I want to work with to fit my technical interests?
Hypothesis: Yes.
Conclusion: Yes. When I left the Biggest Blue Java shop, I made a promise to myself not to work with technology I don’t like. I’ve built many Ruby on Rails and Objective-C products, and I’ve got projects with Erlang, CoffeeScript and even Prolog in them, all of which I really enjoy. The couple of side trips into C++, Flash, Flex, and Java have been few, brief and mostly self-inflicted (Ouch, I forgot how much that sucks! Note to future self…).

Experiment: Can I pick and chose the projects I want to work with to fit my interests?
Hypothesis: Yes.
Conclusion: Mostly no. My main interests are self-improvement, philosophy, literature, sports, alternative software development technology, and education. I’ve had some luck building products in the field of sports, but other than that, I’ve not had much interest aligning my interests with my bootstrapped entrepreneurs’ product needs. I’ve built many branded marketing apps. I’ve built scientific apps, quality assurance apps, customer service apps, healthcare apps, etc. All of these have been very interesting in their own right and I’ve learned a ton with each one. But when I work on my own products as Snooty Monkey, I have a perfect fit with my own interests (Snooty Monkey’s two current products are in self-improvement and sports). This kind of alignment is a powerful force that should not be undervalued.

Experiment: Can I mantain my own high ethical standards while contracting my time to others?
Hypothesis: Yes.
Conclusion: Mostly yes. I’ve been extremely impressed with the character of the entrepreneurs I’ve been fortunate to work with. I regularly hear and read about startup horror stories starring villainous and greedy entrepreneurs. But the entrepreneurs I’ve met and agreed to work with have been some of the most upstanding people I know. They’ve been impeccably fair to me and to their customers. I’m close to suggesting a hypothesis that entrepreneurs are better people on average than society at large would lead you to expect. The one exception to charting my own ethical course has been in the area of software patents. Unfortunately I’ve not seen eye to eye with some of my very best clients about the nature, value and ethical standing of the broken US patent system. The work I’ve done in just the last 3 years has led to over a dozen patent applications, many of which I directly helped formulate (Snooty Monkey does work for hire so those patents belong to the clients). I’m not proud of this. It is a case of my deeds not living up to my thoughts and words. I’m considering declining to directly participate in software patent activities in the future. This could cost Snooty Monkey valuable business.

In looking back over these questions, I find it a bit difficult to remember how scary and unknown they seemed at the time, I can’t help but be pleased at how things have turned out.

The risk I now face is that I become complacent. I’m my own boss, I have a decent income, and I get to work with great people, my team of contractors and bootstrapped entrepreneurs, who want nothing more than for me to succeed. After all, me succeeding is the only way my clients get to succeed. There are no politics, no ulterior motives, and no bureaucracy. It’s the business of software in its purest form. Just them and their idea and me and my keyboard.

In some sense then, I’ve become too successful at what I do now, which is helping others build software companies without taking or before taking investment. This is now an 80-hour-a-week job for me. I could do nothing else for the foreseeable future. But it’s not what I set out to do. It was all a means to an end. That end being to build my own bootstrapped software company. And not just any software company. I want to create software products that help me improve my life, and if all goes well, help others improve their lives in the same way.

I’m ready to admit that I’m no longer making any progress on this. I’ve done some really amazing and cool things since starting Snooty Monkey. I wrote a book, I created some great products, I’ve even helped create what are now some great companies. But I need to get this train back on the original track. I need to better balance the two parts of my business. I need to manage my goals, my time, my tasks and my attention to achieve more. I need to improve myself. I need to be better.

I owe this to myself, I owe it to my family, I owe it to Snooty Monkey’s contractors, clients and current and future customers.

During the last couple of weeks I’ve been working with Andrew (one of said contractors) on the seeds of a new plan. This plan is going to germinate and change and grow (or shrivel and die) here in the open on this blog. Get your popcorn ready! It’s going to be an exciting show.

Build Erlang R14Bx on Mac OS X Lion

Wed, 27 Jul 2011 08:42:00 -0400

Usually to build software from source on Linux or Mac OS X, you follow the pattern:

./configure
make
sudo make install

When trying this on Mac OS X Lion you’ll find that make is no longer part of the OS like it was with Snow Leopard and before. Instead, it is part of Xcode 4.1 or greater. So you need to head to the Mac App Store app and get your free copy of Xcode 4.1 (or greater) so that you’ll have make installed.

Another wrinkle, specifically for getting Erlang from source, is that there are some obscure flags you need to use with configure to get Erlang to build cleanly. This sequence works (tested on Erlang R14B03 and Lion 10.7 (11A511):

CFLAGS=-O0 ./configure --enable-darwin-64bit
make
sudo make install

Thanks to the community on the Erlang questions mailing list for collaborating on this solution. I’m just passing it along.

Erlang's Treatment of Memory and Threads

Wed, 13 Apr 2011 11:08:37 -0400

Erlang's Treatment of Memory and Threads:

This is a good, short post on Erlang’s unusual treatment of memory and threads. Substitute “Ruby” or “Python” for “Java” if it makes it easier for you to understand and none of the comparisons will be much different. It serves to explain why you overlook Erlang’s quirky syntax (which I happen to mostly like) when you need extreme concurrency.

Bringing Serendipity Back

Wed, 16 Mar 2011 08:13:00 -0400

If Timberlake can bring sexy back, then I guess dictionaries can bring serendipity back too. I’m a regular user of online dictionaries and they all seem about the same to me (which is to say, somewhere between pretty bad and awful) so I use them through Google rather than having a go to favorite. I search for the word and then pick one or more of the top 10 hits to look at.

Today a search on the word “monotonist” (I know what it should mean, but I said it the other day, and then wondered if it was actually a word or if I just made it up) brought me to this fairly gross site - http://www.websters-dictionary-online.com/definition/monotonist (linked with nofollow to avoid giving them any link juice). I’m certain, due to the suspicious lack of branding, the poor performance of the page loads, and the dubiousness and quantity of its ad content, that it’s not actually associated with Webster’s (which is here - http://www.merriam-webster.com/).

What caught my eye was this part of the page:

How cool! I can’t begin to count how many hours I spent unintentionally reading the dictionary as a kid. I’d ask my parents how to spell a word, or what a word meant, and they’ d inevitably answer “d-i-c-t-i-o-n-a-r-y” or “it means you should look it up”. I’d traipse over to the family set of the Funk & Wagnall’s encyclopedia (bought from the grocery store on subscription, those were the days!) and its accompanying dictionary (in 2 volumes) and look up the word. Once I found my word, I could never resist the siren call of the other words on the page. Mixed among the handful of words I knew were amazingly short words, gigantic polysyllabic monstrosities, foreign words without enough vowels or with too many vowels, and words with accompanying black and white pictures, line drawings or maps. Each trip to the dictionary was a multi-paged odyssey through the English language.

Sadly, I doubt my kids, lifelong online dictionary users, have ever experienced this. The Web was invented to provide better context; the raison d’etre of the hyperlink and the subsequent Web server and Web page was to provide context to referenced concepts with just one simple click. But what these online Web dictionaries don’t have is page context. What else is on this dictionary “page”? What is on the “opposite page”? The “next page”? The “previous page”? And why are these words near one another? Is there a shared prefix or root? A shared word of compound words?

Links and the power of the Web to provide context are used in every online dictionary page and it would be hard to argue that the Web doesn’t provide a much better experience for exploring a specific word. You have links to antonyms and synonyms and etymology and stems and related words, and, and, and… But what about the words that are “physically” near this one? I haven’t seen an online dictionary attempt to provide this until stumbling on this shady site.

The “nearness” of words is an important concept in my brain’s structure and in my understanding of English. I don’t think I’m alone in this, but I do think that in the span of just one generation we’ve probably lost that part of the organizational structure of our language in our brains. It’s a shame. We shouldn’t go back to paper dictionaries of course, but there is something for the other dictionary sites to learn from and improve on in this site’s listing of adjacent words.

This is not healthy. All but one (#7 Angry Birds) of the top 10...

Sun, 13 Mar 2011 23:14:00 -0400

This is not healthy. All but one (#7 Angry Birds) of the top 10 grossing applications in the Mac App Store are from Apple.

Also not good: when my daughter asked about the mind mapping tool I use, I told her to get it from the Mac App Store, and then my wife and son looked at me puzzled and said, “You mean in iTunes?” These are two long time Mac users.

Why exactly did the Mac App Store need to be a separate application?

Settling for (the Right) Mediocrity

Mon, 17 Jan 2011 08:24:01 -0500

Settling for (the Right) Mediocrity:

Smart stuff from the folks at Working Software:

What is it that you can compromise on that people may expect, in order to deliver what you consider to be exceptional in a period of time that fits your budget and release schedule? … they may be willing to forgo such pleasantries if you deliver them some quality in your application which they consider to be exceptional. The key to living with mediocrity, releasing software and, hopefully, making money is to figure out which bits of the application you’re building can get away with being mediocre, then spend all your time working on the bits that will make your product exceptional.

Apple is Not a Software Company

Sun, 02 Jan 2011 10:16:00 -0500

Marco Arment, the founder of Instapaper and former tech lead at Tumblr recently wrote that there really isn’t much of a market for tablets, just for iPads. I have no bone to pick with his main point, he’s right about that. But part of his analysis is way off base (the bold emphasis is mine):

And, like they’ve done so far with Android, the hardware manufacturers will continue to attempt to make their own user-facing applications and front-end interfaces, but these usually suck. (Other people may describe “suck” with kinder, apologist adjectives like “getting better” and “not bad”.)

These manufacturers aren’t software companies: they’re hardware companies that write software out of necessity. Apple is a software company that makes hardware out of necessity. The software side of a modern computing platform is far more difficult and expensive to create and maintain than the hardware. Anyone can cobble together the same processors, DRAM, flash, and radios as Apple, put them into a plastic case, and run a commodity OS on them with slight front-end customizations. But not everyone can create an entire software platform.

Apple is absolutely not a software company that makes hardware out of necessity. That sells Jonathan Ives and his team of brilliant industrial engineers short. Creating innovative hardware is still very hard. Copying Apple’s hardware is easier, but still difficult; it takes a few tries to get right.

I can see where Marco is going with this, he wants to paint a simple picture of two types of companies, hardware and software companies. He wants to put Apple, Google and Microsoft into the software category and all the other tablet makers that use Windows and Android such as HP, Dell and the Asian manufacturers into the hardware category. He then wants to say good software is really hard and good hardware is really easy, so the tablet manufacturers that aren’t software companies are stuck. Apple makes their own hardware so it works fantastically well with their software, but the hardware companies are forever disadvantaged because they can’t make software that will will work fantastically well with their hardware.

This is just not an accurate picture though, Apple is not a hardware company dabbling in software or a software company dabbling in hardware. Apple is the last of a breed of something we used to have a lot of, a systems company. Systems companies create systems composed of hardware and software.

I’m not sure how old Marco is, but I’m guessing he’s a bit younger than me because I can remember a time when the computing landscape was dominated by systems companies: IBM (z/OS, RS/6000 and AIX, PS/2 and OS/2), DEC (VMS), HP (HP 3000, HP-UX), SUN (SPARC and SunOS/Solaris), Silicon Graphics (IRIX), Apple (Mac), Be (BeOS and Be Machine).

In a classic disruptive move, Microsoft and it’s flock of PC OEM’s (Dell, Gateway, Acer, etc.) killed off the systems companies one by one, either outright, or by forcing them to abandon their systems (HP, IBM except for the mainframe) in favor of becoming a Windows OEM. Apple is the only one that survived as a systems company at a time that didn’t favor the systems companies; hardware compatibility was king and hardware innovation was static (More’s Law was driving all the innovation).

Now that Moore’s Law is breaking down and innovation in hardware form factors and interfaces is back on the top of everyone’s agenda, it’s a great time to be a systems company again. Apple is outperforming their technology peers, and we all want iPad systems, not some hardware devices running Android or Windows software.

The Golden Football

Fri, 24 Dec 2010 07:47:43 -0500

The Golden Football is a new description by Evan Miller of the economics of GroupOn. The idea is that GroupOn moves the economic activity to the right of the normal micro-economics price/demand curve by offering up a lower price than the market has settled into charging for that particular good or service in exchange for a higher volume than the market would normally demand for that good or service at that lower price.

The Golden Football is formed from happy customers getting a price lower than they’d pay…

And from business getting more quantity of sales than the price would normally generate, and therefore more profit.

It’s an interesting model, and very different than the loss leader / lifetime customer value story that’s normally told about GroupOn.

All the graphs and the model are courtesy of Evan, I’m just trying to spread the word so that hopefully some enterprising economist will test the model or some entrepreneurs will validate it by applying it in new ways.

The $20 Starbucks Test

Thu, 23 Dec 2010 11:06:00 -0500

A couple of weeks ago I had the good fortune to meet Hugh Crean, the ex-CEO of Farecast, ex-Microsoft executive (they acquired Farecast) and current Entrepreneur in Residence at General Catalyst. A group of us talked to Hugh for close to an hour, and I learned more about the travel industry in that short span than I’ve learned in a lifetime of flying, hoteling and using Kayak, Priceline and the like.

The purpose of our chat with Hugh was to get some feedback on a project we are working on, and Hugh shared a cool $20 technique for validating your new product, service or startup idea that I’d like to pass on. Here is how it works:

Get yourself a nice crisp $20 from an ATM
Go down to your neighborhood Starbucks
Walk up to strangers with empty coffee mugs and tell them you are worried about your brother, need some advice, and can you buy them a cup of coffee in exchange for a quick 5 minutes of their time. (This will be awkward for most of you to do. Get over it. The “worried about my brother” line is a bit of psychology that means most people won’t turn you down. If they do turn you down, you just got a point in the Rejection Therapy Game anyway, so consider yourself lucky).
Buy them a simple coffee, not a mocha-whippa-frappa-latta-chino; you want your $20 to last.
Explain that your brother has a crazy business/product idea, and that he’s about to get a 2nd mortgage on his house, raid his 401k and quit his job. His wife is a nervous wreck, afraid that they’ll lose their house and retirement fund, and he’s hit your parents up for seed money that they really can’t afford to lose. Your parents and your sister-in-law have come to you for help to try to talk him out of his hair-brained scheme.
Explain that this is where they come in, your brother is a very logical and reasonable guy, and can be convinced by good reasons, but he has been blinded by thinking this is a really good idea. The problem is, you sort of agree with him, so you need some really solid reasons to give him as to why his idea won’t work, and why he shouldn’t proceed with his plan. Then… pitch your idea! Sell it the best way you can. Respect their time (you asked for 5 minutes), but give the best 2-3 minute pitch you can.
Now, ask for their reasons the idea won’t work. Keep them focused on the idea, not the backstory (they may want you to convince your brother of the merits of retirement savings or the dangers of 2nd mortgages), and really listen. Resist the temptation to argue against their objections. Then thank them heartily for their time.
Repeat until your $20 runs out.

What will you learn from the experiment?

The most likely outcome is you’ll hear mostly the same obvious rejections of your idea that you yourself have and have come to believe are surmountable. Your $20 didn’t generate any great new insight, but was an inexpensive check that you aren’t blind to an obvious shortcoming.

A good outcome, is that you hear lots of interesting and sound new objections that you never thought of before. This should give you real pause about your idea. Both its merits, if the objections are good ones, and the extent that you’ve sufficiently thought through your idea and are being realistic about it.

A not so likely outcome is that your strangers will find themselves agreeing with you and your “brother” that it is a great idea. They themselves will want to buy the product or service and they’ll start naming other people that need it. They’ll also probably apologetically offer up a few lame objections, because that’s what you asked for. In the unlikely event this happens with your idea, you probably have a real hit on your hands. Run with it!

Two quick caveats… this works best for a consumer product or service. If your idea is for a better steel retracting refluxerator for pediatric heart surgeons, then the man on the street in the coffee shop might not be a great source of insight. Also you have to get comfortable with the white lie you’ll be telling about your “brother”. If you can’t get comfortable with that, it’s understandable, but it is an important part of the technique. The negative priming and the distancing of yourself from the idea gives your coffee companion free reign to trash your idea so find some other way to provide some distance from the idea. If instead you say it’s your idea, then even when you invite criticism and honesty, people will candy-coat their feedback. Luckily our social norms will not stand in the way of them trashing your brother who’s not in the room.

"Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it."

Sun, 19 Dec 2010 16:58:06 -0500

“Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it.”

- Alan Perlis

Always Be Building Your Own Products

Sun, 19 Dec 2010 08:58:00 -0500

Like many small technology companies, Snooty Monkey makes the mortgage and the payroll through work for clients while carving off time to build products. It’s not ideal, but it beats the alternatives: working a corporate job for years to save up a financial runway, or ceding autonomy to outside investors, who of course get a say in how their money is spent.

Once you have built a successful services business in a niche that matches your passions and interests (in the case of Snooty Monkey, building brand new products for entrepreneurs), you can start to ask yourself: this is profitable; this is fun; why not just do this forever?

Even if your long term goal is to have a services business (or be a freelancer) and build products for other people, you should never stop building your own products. There are important professional obligations that client work brings. Being free at times from those obligations is critical for long term success.

#1 Learn radically new stuff

When working for a client, you have an obligation to manage technical risk and to properly represent your experience and skills. Both of these work to prevent you from learning radically new stuff “on the clock”.

Managing technical risk involves choosing a sound technology that’s suited for the task at hand, that’s robust and relatively bug free, and where you have a reasonable assurance that they’ll be future development to fix bugs, fix security issues and adapt to new operating systems and language versions. You also are obliged to choose technologies that are readily picked up by someone else should you get hit by a bus. If you are the only Logtalk programmer in a 4 state radius from your client, it’s probably not a great idea to build your client’s project in Logtalk without their informed buy in.

Representing your experience and skills is all about communication and honesty. If you literally wrote the book on a given technology, say so. If you are waiting for your copy of the book to arrive from Amazon, and will know more next week once you get to chapter 2, say so! When hiring freelancers or project teams, clients are usually paying for more than your raw intelligence. Part of your rate derives from your skills and experience with a technology. If you don’t have said skills and experience, many clients won’t be interested in you learning them on the job, and others may expect a break in your usual rate until you come up to speed. This is a reasonable position for your client to take if your usual rate properly reflects the skills and experience you bring to the table.

That’s not to say a given client might excuse you from all these obligations and give you free reign to learn a risky new technology that you have no experience with on the job. But that’s a double rainbow client. Don’t expect to have them.

None of this precludes trying new things and continual improvement. You also do your clients a disservice by never learning, adapting and improving. Each project should be better than the last. Always been a Test::Unit user but want to use RSpec for the next project? Want to switch from your tried and true restful-authentication to the new hotness, authlogic? These evolutionary improvements are not what I’m cautioning against in client work. It’s the big disruptive changes that make you suck for a long time until you “get it” and that you have a good chance of deciding are a mistake and abandoning.

So how do you make those big leaps forward that require a huge step back first? Do them on your own time of course. And rather than building the blog sample from the book or some other toy project, you might as well try building a useful product. You’re going to invest the time in the new technology anyway, if it turns out to be great stuff, it’d be great if you got a fantastic new product out of it along the way.

In that vein, Snooty Monkey kicked off the development of a new product last week; the idea for it has been kicking around since Summer. Some weeks we’ll spend no time on it, some weeks we’ll be able to carve out a few hours or a whole day. Our “rule” (admittedly arbitrary) is, everything has to be new. The main purpose of the project is learning and having fun. The secondary goal is creating the product (if it was the primary goal, we’d use the tried and true technology stack).

Out: MySQL In: CouchDB

Out: Ruby In: Erlang (the 1 tiny exception to the rule, it’s new for all but 1 of us)

Out: Rails In: Nitrogen

Out: XHTML In: HTML5

Out: JavaScript In: CoffeeScript

Out: AJAX interval polling In: Comet and Web Sockets

Out: CSS In: LESS

Reader’s imaginary Socratic dialog section:

Q: Is this choice of technology driven by the needs of the project or is it a bit gratuitous? A: Uhh… the tail is wagging the dog.

Q: Will you be able to build the new product as fast as you would if you used a tech. stack in your comfort zone? A: No.

Q: Will you be able build a successful product with it? A: Dunno.

Q: Will you learn a lot? A: Hell yeah!

Q from a Geek: Is it going to work well to combine CoffeeScript with all the JavaScript generated by Nitrogen. A: Dunno, waiting for that CoffeeScript book to get here from Amazon. We’ll find out. But I think you missed the point. Go back to the top and re-read the post.

#2 Reconnect with your inner customer

The other great reason to not stop building your products is empathy. Being a “customer” of your own services stokes the flames of empathy. It’s important to walk in your customers shoes, to put yourself in the position to care about the same things they care about. Are you sitting your customer down for the three legged stool talk (“Sorry Jack, scope, time or resources; only 2 can be fixed…”) yet again? When was the last time you sat yourself down for the same talk?

Treat yourself like you treat your customers. Don’t give yourself special breaks and exceptions you wouldn’t give them. Make a budget (in time, not dollars) and try to stick to it as they have to. How easy do you make sticking to the budget? Are there things you are doing, such as lots of tangential work on the project that’s not core, or a lack of timely visibility and tracking that make it hard to stick to it? Or are you so fixated on the budget that you sacrifice the other goals of the project?

Most important to rebuilding the empathy with your clients is to scratch your own itch with the product. Build something that you are madly passionate about, and that you are the customer for. It’s easy to slip into a calloused, distanced, assembly-line mode of working when building product after product for customers. You need to rekindle the spark that comes when you are building something that you are truly obsessed with. By reminding yourself what it’s like to care so much about the outcome, you’ll be better able to empathize with your clients.

Erlang native compilation, why not?

Wed, 15 Sep 2010 10:27:14 -0400

belucid: what are the downsides of compiling Erlang native? (HiPE) Any reason not to use it all the time?
MononcQc: the native modules aren't garbage collected when loading a new version
MononcQc: also they are not portable like .beam files
MononcQc: they're slower to compile and are not necessarily faster
MononcQc: but they are entirely worth it for numerical stuff
belucid: ok
belucid: so I should run some perf tests with both
belucid: and see if it makes a diff for my application
MononcQc: ideally, yeah
MononcQc: always measure
belucid: yep
belucid: and then... if they do make a meaningful diff, the impact is that I really shouldn't plan to load new versions
belucid: and of course, need to compile for the target machine
MononcQc: oh, load new versions all you like
MononcQc: it's not a big overhead
MononcQc: just something to consider
belucid: ok
belucid: just shouldn't plan on loading new versions forever and ever then
belucid: at some point it would add up
MononcQc: yeah, but then you'll need to tear the node down to upgrade the VM
MononcQc: so I'm not sure it's actually that problematic in practice
belucid: gotcha
belucid: on days like today, Erlang R14B release day
belucid: you'll bring the app down anyway
belucid: thanks as always MononcQc!
MononcQc: no problem

The Erlang Shell

Mon, 13 Sep 2010 09:19:40 -0400

One option to running the Erlang shell when your code is in ./src, including files in ./include, and building to ./ebin is to run erl from ./src as such.

erl -pa ../ebin

All your modules are then local and can be accessed. You can include records with rr(module).

Thanks MononcQc on #erlang.

"From a single bit to a few hundred megabytes, from a single microsecond to a half an hour of..."

Mon, 06 Sep 2010 17:16:45 -0400

“From a single bit to a few hundred megabytes, from a single microsecond to a half an hour of computing, it confronts us with completely baffling ratio of 1 to 1,000,000,000! The programmer is in the unique position that his is the only discipline and profession in which such a gigantic ratio, which totally baffles our imagination, has to be bridged by a single technology. He has to be able to think in terms of conceptual hierarchies that are much deeper than a single mind ever needed to face before.”

- Edsger Dijkstra via Manuel Simoni

rm all the results of a find

Wed, 01 Sep 2010 10:03:02 -0400

rm all the results of a find:

I’d never had the need to remove everything found by the find command before. Since rm expects arguments, rather than piped input… it breaks the normal Unix pipe it all together paradigm.

Some quick googling brought xargs into the picture though. xargs constructs an argument list from its piped input and executes its argument with them. Perfect for what I was trying to do:

find . -name *.pyc -print0 | xargs -0 rm

Stop Reading Business Books

Tue, 31 Aug 2010 09:24:34 -0400

Stop Reading Business Books:

There are 2 types of business books, the pop culture, high-level, feel good business book, and books with real data and case studies by scholars. Both are equally bad for most readers. Let’s start with what Rob Walling has to say about the former:

“…these books are a series of anecdotes disguised as science.”

Amen brother! As someone who is in business, but is also educated in science and logical thinking, these Seth Godin / Malcolm Gladwell / Chris Anderson / Clay Shirky books make me very squeamish. Their lack of scientific rigor is both fundamental to their popularity and their fatal weakness. I love them, but it’s a guilty pleasure.

“The amount of actual information garnered from this kind of book can be summarized in a page or two of written text.”

They are a dinner of ice cream sandwhiches and popcorn. A couple bites are OK, but reading 150, 250 or 350 pages of these books is an incredible waste of time. There is such repetitiveness and rambling drivel in these things to get them to the publisher’s desired page count that it’s a crime against their busy audience’s time.

It seems like the antidote then should be serious business books from academics at respected business schools. Not so fast:

“… these books are great … if you’re Sony. Or Proctor and Gamble. Or Panasonic …. This information would be helpful if I needed to generate a huge business plan to impress a business-school professor …. They speak to markets and business opportunities measured with 8 zeros or more. Massive markets that you don’t need to understand to run a software company.”

I’ve found the same to be true of these books. Are they interesting? Yes, very. Helpful? No, not really.

I’ve only been at a company big enough to apply these types of theories once in my life, and even then I was not high up enough at IBM to put anything I was reading into practice. Working at the individual product or product group level at a company like IBM resembles a startup more than you’d think. It’s just a startup that’s got one hand and one foot tied behind its back in a not unreasonable effort not to be sued for the billions in cash they have.

The lure is strong. Resisting is hard. I succumb myself too often. But do keep up the good fight and try not to read these things.

The Bowling Pin Strategy

Sun, 29 Aug 2010 08:09:45 -0400

The Bowling Pin Strategy:

“…find a niche where the chicken-and-egg problem is more easily overcome and then find ways to hop from that niche to other niches and eventually to the broader market…history suggests that big companies who rely on a ‘carpet bombing strategy’ are often upended by focused startups who take over one niche at a time.”

5 Reasons Not to Share Your Roadmap

Sun, 29 Aug 2010 06:48:23 -0400

5 Reasons Not to Share Your Roadmap:

There is always a strong temptation to share the product roadmap. It is rarely a good idea because of the flexibility you give up.