Speaker training at Linux Collab, LinuxCon

Are you a first-time speaker?  Have you noticed most of the audience checking their email during your talks?  Are you speaking to a mostly-empty room, and not getting invited back to conferences?  Do you walk out of the room thinking "that could have gone better"?  Are you a brilliant technology inventor, yet at a loss when standing in front of an audience?  Are you just regularly speaking at conferences, but have never attended a speaker training before?

If the answer to any of the above is "yes", then you need to attend my speaker training at the Linux Collab Summit or at LinuxCon this year.  I'll be reprising "Give A Great Tech Talk", the speaker training Ian Dees and I developed for Open Source Bridge -- with some improvements, additions and advances, of course!  This session is strongly recommended for all new speakers by the Linux Foundation, and even experienced speakers can pick up a few useful tips.

Since we'll have a longer timeslot for this than we did at Open Source Bridge, I'll be doing more audience exercises.  If you're attending, please bring your notes and slides for some of your own presentations, and we'll work on them.

See you there.
  

PostgreSQL's New Development Priorities: Part I

Six years ago, I came to the first Developer Meeting for PostgreSQL in Ottawa -- it wasn't even called that at the time, we just sort of pulled a bunch of people together -- with a list of the five big features which PostgreSQL was missing.  We'd just eliminated a big obstacle to Postgres adoption by creating the native Windows port, and these were the remaining five technical issues which most frequently caused people to evaluate PostgreSQL and decide not to use it.  These were:

1. Difficulty of install
2. Lack of built-in simple replication
3. Performance for web applications
4. Driver quality
5. Difficult configuration

As you can tell, a lot of the above was taken from interviews with MySQL users, but they were all legitimate issues.  Thing is, the PostgreSQL community in versions 8.4 through 9.2 pretty much eliminated the first three issues, the fourth was addressed by Rails, PHP and Python without any help from us, and the last item is well on its way to being addressed in 9.3.    There's still stuff left to be done; better autoconfiguration utilities, better OSX install, LinQ driver for .NET, etc., but as top priorities the above issues are largely under control or in the process of being fixed.

So what's next for PostgreSQL development?  What do we need to do, technically, to continue as the #1 open source database?  I plan to address this in a series of upcoming blog posts.


(note: I'm aware that a large chunk of database adoption is driven by non-techical issues.  However, that's not what I'm addressing at this time.)

Change of Color Scheme

Based on multiple comments from the intertubes, I've changed the color scheme of the blog.  Hopefully people like the new one better.

NoSQL Partition Obliviousness

Just a quick note to draw people to an excellent blog post about NoSQL databases and "Partition Tolerance".  Emun Sirer points out one of the many reasons why "webscale" doesn't mean what you think it does, and how not all new scalable databases are the same.  He doesn't say which specific new database is marketing features they don't really have, but I think we can guess, can't we?

20 Rules of Software Consulting

I'm going to be gradually republishing some of my older content from my prior blogs here so that people can find it again.  I'll also be updating the stuff which needs updating, of course.   Here's a revised and updated favorite: the "rules of software consulting".

1. Technology Reflects the Business: show me a client with a chronic software problem, and I'll show you a client with a chronic management problem.
2. Three Things You Will Never See:
   a. A timeline which is too generous;
   b. A client who pays too quickly;
   c. An accurate and complete specification.
3. Half of Applications Are Immortal: "temporary, one-off" applications often last for years, and there is code from the 1960's which is still running today. Always plan for longevity.
4. Bad Clients Will Destroy Your Business: half of your success will be built on the ability of recognizing bad clients and avoiding them or terminating their contracts before they suck away all of your time and resources. Always be able to walk away, even if it means giving a refund.
5. Ask Not What's Possible: the question is not what you can do, the question is how much the client is willing to pay for it and how long they will wait.
6. Time Substitutes for Money on a Logarithmic Scale: e.g cutting the time by 20% will require doubling the budget. Cutting the budget by 30% will quadruple the amount of time.
7. All Estimates are Optimistic: new application development will take three times as long as you expect, and cost twice as much. Or vice-versa.
8. Three Things You Will Never Have Enough Time For:
   a) The specification and prototypes
   b) Documentation
   c) Code maintainability
9. All Substantial Applications Have Platypuses, which are objects or bits of data which defy all attempts to fit them to well-defined business processes. Platypuses are both why perfect data integrity is unachievable, and the source of at least 30% of troubleshooting.
10. Don't Call it Refactoring:  clients never pay for cleanup, even if that's what they need.  Figure out a way to call the refactoring something else so you can get it done.
11. The Longer You Wait to Refactor, the Longer It Will Take. Major template or schema changes at production time are particularly deadly.
12. Always Have a Contract, even for one-day jobs. Also, use your own contract, and not the client's, and have your contract written by a real attorney. It's worth it.
13. The Contract-Writing Process Is a Litmus Test for Its Fulfillment. If the client spends a lot of time arguing over the contract, then actually working with them (or getting paid) will be even more difficult. If the client insists on an odd and obscure clause, they're planning to exercise it.
14. The Client Has Very Poor Memory: no matter what they sign, the client will have forgotten what they agreed to within days, if not hours. Document all requests and changes and keep copies.
15. Never Agree to a Fixed Bid for anything where you have not done the same exact task at least twice before.
16. Third Parties are Incompetent: never agree to a fixed bid or success-based payment for any task which is even partially dependent on the speed, documentation or product quality of a third party not under your direct control. This means no fixed bids for data interchange or fixing other people's code, ever.
17. The Client has No Taste: never allow the client to choose your tools, your subcontractors or your work environment. Or at least charge them a lot extra for the privilege.
18. Always Bill for Meetings, or you will spend half your life attending them.
19. A Half-Empty Mailbox Is The Exception: usually, if one client decides to pay unusually late in a month, all of your clients will. Always be able to survive 60 days on your savings.
20. A Sufficiently Late Project Will Never Be Completed.  In general, any project which is more than 150% past its original deadline has sufficient systemic issues to permanently prevent delivery.

PyPgDay Sold Out

As of yesterday, the first PyPgDay is sold out.  We're expecting between 130 and 140 attendees, which isn't bad at all for a one-day, one-track conference.   If you haven't registered already, sorry!  We've also added a fundraising raffle, thanks to Mark Wong making us another uber-cute elephant, so bring your cash.  Drawing will be held at the Salesforce party.

Too bad PyCon is in Montreal next year; we'll have to find another way to do a Bay Area Postgres event in 2014.