Open for business in Peru

This is my last week in language school (at least until I need a refresher course) and with it come some big changes. My family has settled in to life in Arequipa, at least to the extent that can be expected after five months in a foreign country speaking a new language. I have received my work visa and have started a Peruvian company to focus on training / consulting for software developers.

My first client / partner is Lima-based Tekton Labs, which has hired me to provide technical training and architectural guidance to the cloud and mobile development teams. I am looking forward to working with the team for several reasons:

1. Tekton has a talented team and strongly believes in personal development. This is very important because, while there are a few good computer science programs in the country, there is no substitute for continuing education in our field.
2. The company has a mature, agile software development process (Scrum), which in my view is a prerequisite for taking on large projects.
3. Tekton has a sizable portfolio of work for large enterprises, but still offers significantly lower prices than US-based companies.

In the US, some of the most coveted jobs in programming are with Internet and software companies. In Peru, on the other hand, they are in finance and telecommunications because they typically pay the best ($500 – $2,000 / mo. + benefits). Unfortunately, this means there are few cloud and mobile jobs here; however, there ARE talented developers with the necessary training as well as self-taught hackers just like in the US. My aim is to help provide further training for these developers and to connect them with US-based companies like startups who may have great ideas, but can’t afford US-based labor. Over the next year or two, I’ll keep you posted on how it’s going. In the mean time, if you have an idea which might be a fit for a Peruvian development team, ping me on G+ and let’s talk.

Advertisement

Salespeople vs. developers in a software startup

Joel Spolsky is one of my heroes, partly because I strongly agree with his people-first philosophy of management, partly because his flagship product, FogBugz, is a work of genius (calculates ship dates as a probability curve, not a binary event), and most of all because Joel has built a successful software company in one of the most overcrowded fields (bug tracking software) while living and working in one of the highest-rent cities in the world (NYC).

Joel’s latest is perhaps the single most memorable thing I have ever read on the subject of software quality and marketing. If you’re starting or running a software business, Joel on Headcount will be well worth the 2 minutes it takes to read it.

The ISV is coming back (thanks to AppEngine)

Someone at last night’s AJUG meeting articulately expressed what I’ve been thinking for the last several weeks as I’ve been learning Google AppEngine: this platform gives the independent software vendor (aka “the computer guy at your church”) a new lease on life. Why will AppEngine bring back affordable custom programming for small business?

1. There are no servers to configure. Sys admin and tech support are the bane of every developer’s existence, which makes AppEngine a developer’s dream. Code, test, and deploy. No sys admin needed.
2. There’s nothing to buy up front: no servers, software, firewalls, backup solution–not even hosting fees until you exceed AppEngine’s generous usage limits.
3. You can log on to your AppEngine application with your Google account (Gmail) or Google Apps login. For many businesses, Google Apps is a compelling alternative to running your own file and document servers and paying for MS Office on every desk. If everyone in your business already has a Google Apps account, it’s a no-brainer to use AppEngine for your custom apps, too.

As more folks learn how to create AppEngine apps in Python or Java, I expect there to be low-cost applications you can purchase for your business as well as pre-packaged applications that developers can buy and customize for your needs. The fabled long tail of software niche marketing is set to EXPLODE.

Shameless plug: if you’ve always dreamed of having software that could do (whatever) for your business, but thought it was probably too expensive, drop me a note. The game has changed.

Quality doesn’t end with the sale

Want to know why Toyota is the #1 selling car in America? I know one reason why. I recently purchased my first foreign car, a 2004 Toyota Sienna, from a third party. After a few months, the driver door started squeaking and popping when opening and closing, and the rear liftgate was starting to hesitate a little on opening. How disappointing to one who had expected the famed Toyota quality!

But wait, there’s more. I took it to my local Toyota dealer, who informed me that Toyota had extended the warranty for this issue to 100k miles, and also informed me of an active recall involving the rear liftgate struts. These were the major things wrong with the car, and both were fixed at no charge, even though I’m the second owner of a car with 89k miles and didn’t buy from the dealership! Until now, I’ve never heard of a manufacturer extending the warranty retroactively for a particular issue! GM and Ford think that TV commercials inspire customer loyalty, but Toyota understands that quality and service inspire loyalty, and neither ends when the car rolls off the line.

Does your software have enduring quality?

/dmc

David’s Laws of Management

1. Love your people. Listen to your employees. Give them the tools & support they need to do their jobs. Clear roadblocks. Keep hope alive. Act as though the people closest to the work are the ones with the best ideas about how to improve it. Empower them to fix what’s broken.

2. Have a plan. This is one of the greatest ways you can serve your people. If you do nothing else, when employees ask “which of your #1 priorities do you want me to work on today?” you should be able to pick one. If you can’t, what do they need you for? No problems worth solving can be solved without focus.

If You’re Too Busy, You’re Not Doing Your Job

Much has been written about the virtues of the lazy programmer, the one who never likes to write the same code twice. For the lazy programmer, coding anything once is fun because it’s a learning experience, but coding it twice is tedious. Not only that, but also it is dangerous because manual repetition means there are too many degrees of freedom for error. And not only that, but doing the same thing twice when you could have done it once is WASTE. One of the principal ways you improve throughput in any system is to eliminate waste (think for just a moment about your body).

The brilliance of the lazy programmer is that he can recognize when he has just done the same thing twice. Others don’t see they have done the same thing at all. In other words, the lazy programmer’s mind works at a higher level of abstraction. He can factor out the common code in the right dimensions and build abstractions so he never has to generate waste by writing that code again (and of course, this is fun because it’s a new kind of code). Then he sees the common factors in the successive versions of those abstractions, and after 10 years or so, can build something as beautifully well-factored as, say, JavaServer Faces.

I submit that the same ability for abstract thinking and automation are key requirements for Operations and QA, too. For an Ops guy to follow a standard procedure for system installations is mere competence (if the Ops organization has no such procedures, the Ops manager should be replaced–there is no excuse for such a lack of discipline). The truly great Ops people learn a system well enough to automate its installation and maintenance. They wield power tools with funky names like sed, perl, bash, and even InstallShield. They can run some command that will reinstall and reconfigure every server on the network in the event of a disaster and they know it works because they use the script for daily installs.

But, alas, like the lazy programmer, the lazy ops guy is rarely seen. In his place are (very) hard-working drones who manually repeat the same steps day after day, spend most of their time reacting to the perpetual crisis, and wonder why they live in a world of chaos.

If your Ops people are always busy, it might be a sign that they aren’t doing their job!

/dmc

How to Hire Good QA People for Web Applications

A veteran software manager recently gave me same valuable insights on finding highly productive and effective QA people.

These two questions reveal a great deal about someone’s mindset and approach to software testing:

1. How do you generate large amounts of test data?
2. What are the pitfalls of automated Web testing and how do you get around them?

Unfortunately, the people running many QA organizations don’t understand these things themselves and wonder why their automated testing efforts repeatedly fail. Those rare few who do and ‘splain it to them are prone to get fired because it’s not safe to be smarter than the boss.Almost any programmer can tell you what you need to do to deep testing of a system: how to test each subsystem, how to generate meaningful test data that will really exercise the system, how to do positive and negative (no side effects) testing directly in the database vs. relying solely on what shows up on the screen, etc. In other words, the programmer knows more ways the system can (and can’t) fail because of their knowledge of how it works.

QA and Development should talk more often.

When Wishes Come into Conflict with Reality

“We don’t have time to do it the right way!” a software development manager recently told me, “because we have to deal with the reality of a looming deadline.” (Never mind that doing it the right way would allow us to do it only ONCE, thus conserving time down the road. And never mind that doing it the right way will result in higher quality, which always saves time).

I expect to hear this old fallacy from some project managers and client representatives, but not from a development manager. What is the fallacy? As far as the actual software completion date is concerned, deadlines are WISHES, not reality. The actual completion date cannot be known with absolute certainty in advance. That is REALITY. I once had the pleasure of working with an IT Director J.P. Besong, who articulated the fundamental truth of software projects that still seems to elude most software project managers:

When wishes come into conflict with reality, reality wins.

/dmc

Abstraction leads to profits

I found an interesting quote in an interview with Microsoft great (and very rich man) Charles Simonyi. Speaking of his early days at Microsoft writing their first spreadsheet program, Multiplan, (which was subsequently wiped out by Lotus 1-2-3), he says:

We were competing very effectively against Visicalc using a strategy that is very much like Java today; it was a platform independent, interpretive, bytecoded system, that enabled us at one point to run on 100 different platforms, so we could fund the international organization and get acquainted with localization problems, and all those things.

Abstraction and the reusability it enables is a powerful support of profitability. Object-oriented programming was a step up in abstraction, followed by patterns, and in a related vein, components. What’s next?

According to Simonyi, Intentional Programming, which is yet another step up in abstraction that lets you specify the INTENT of algorithms and relationships in a language-independent, platform-independent way. It will be very, very interesting to see what happens next.

However, the failure of Multiplan may also provide a warning to purveyors of Intentional Programming. Simonyi continues:

Actually, Multiplan, our spreadsheet, remained very popular in Europe, for much longer than in the States. What happened in the States was that Lotus 1-2-3, wiped us out. So that was kind of difficult, but it was our fault. We were betting on the wrong horse — the mixed market with a variety of systems, instead of the right horse, which happened to be also ourselves, namely MS-DOS.

Microsoft, having learned its lesson early, seems to have never repeated the “mistake” of pursuing a multi-platform strategy. Perhaps the apparent conflict of interest between Intentional Programming and the Microsoft cash cow is why we haven’t see it yet. Can Sun beat Microsoft to the punch on this one?

/dmc

The Great Game of Software

Eric Sink’s latest amusing and instructive piece on running a software business….

The Game is Afoot