Start With The Problem

In a sort of followup to a recent post, I will continue to avoid using the term NoSQL, but instead of “NoJoin”, I’ll either use Non-Relational or, Relational, depending on the features of the database.

The reason why is that many of the popular scalable databases are non-relational, e.g., they’re key-value stores, document stores, graph-based, etc., which means they’re trading off normalized data storage for speed (among other aspects, really it’s consistency, but I’m not diving into that in this post). However, building on the idea that relational databases don’t have to be monolithic systems, and can be built out of modular components, there’s a new (well, not that new) set of relational database systems that can scale in similar ways to the non-relational databases. Some examples are VoltDB, Google’s Spanner, Akiban, and others that are grouped under the banner of NewSQL (sigh). This is again a bad name because it’s not SQL vs. non-SQL: the way you ask for the information is orthogonal to how the information is stored. I could write a SQL layer on top of, say, riak, but that doesn’t change anything. Anyway, I’m starting to repeat some of what’s written here, as well as elsewhere.

My last post was pretty long, so I wanted to put a “Read more” link after the first paragraph. Since I use the Markdown version of the editor, though, there’s no icon to do a “cut”. It turns out that it’s pretty easy (once you know how, of course), just put the following on a line on its own where you want the Read More cut to be:

<!-- more -->

Make sure there’s spaces around the word “more” and you’re all set!

Disney recently redesigned their online store, but I’m not only disappointed at how hard it is to use, and how many bugs I found, but amazed that such a high-profile e-commerce site was allowed to go live, especially in this day and age of supposed User Experience Enlightenment. Oh sure, the site looks nice, but from a task-oriented point of view, it’s a complete failure.

Read More

As I’ve been studying and playing with the non-relational databases (aka NoSQL), I realized that the name NoSQL is a poor descriptor for these types of databases. Yes, I know, I’m not the only one who’s noticed this, but however you interpret NoSQL, whether it’s No SQL or Not-Only SQL, it’s still wrong, because it’s not that these database don’t do SQL (in fact, some have very SQL-like query languages), it’s that they don’t do joins.

Joins are the underpinnings of relational databases, but are also the hardest things to make perform well. The reason why databases such as MongoDB, Cassandra, CouchDB, Redis, etc., are all so blazingly fast is that they don’t do joins. For example, if you have a table of Employees and another table of Addresses for those employees, and you want to get a list of the employees with their addresses, that’s a join. In a relational database, you can easily combine them to get a nice list. With NoJoin databases, you’re on your own if you want to join them, but the whole point of the NoJoin databases is that you don’t put those two types of information in separate places, you put them in one big table (hey, where have I heard that name before?) and when you want an employee with his/her address, you just grab that document (or value) and you’re done.

Daniel Lemire wrote about this a couple of years ago and so from now on, I’m going to only refer to such databases as NoJoin databases, because that’s the kind of pedantry I can get behind. Won’t you join me? (ha. ha.)

I just published the first chapter of my new book on Jackson, which is a JSON processor for Java (and other JVM languages). Following my “Start With The Problem” mantra, the book is a set of recipes to solve specific problems using Jackson with your codebase. Jackson is a great tool, but because it’s so flexible, it’s hard to know what to do when faced with certain problems.

I’m using the LeanPub platform to publish “early and often”. You can get a sample of the book or buy it at the pre-release special price: http://j.mp/jackson-cookbook.

nulls and ifs are BFF. Discuss.

I was just reading some post-mortems on failed products and connected it with some discussions I’ve been following about Minimum Viable Products (here and here). What I found interesting is that many people seem overly focused on the Product aspect instead of The Problem That People Have.

Read More

Something that I tried to get going at last year’s Lean Software & Systems Conference (aka LSSC) is getting people to show off and talk about their Kanban boards. It never got off the ground, but I’d like to give it a shot at this year’s SFAgile2012 conference. If you’re interested in showing off your physical story walls/kanban boards and saying a little something about it, please let me know.

Who knows, we might even be able to have awards or a contest if there’s enough participation…

Following up on my prior post, another topic I want to see and strongly encourage people to talk about are the “experiments” that you tried as part of Continuous Improvement (e.g., the action items that came out of your Retrospectives). I especially want to hear about the failures: the things you tried that didn’t work, or perhaps didn’t work as well as you’d hoped.

So, if you’re Agile, but maybe you think your successes are just par for the course, come talk about (and celebrate!) your failures. I will wager that discussions about failures will be well-received and appreciated by the community.

The 2nd San Francisco Agile Conference 2012 (aka SFAgile, or @SFAgile2012 on Twitter) is coming in June and we aim to make it a conference for the Agile Community, by the Agile Community, which means we need you to participate.

As part of the SFAgile review committee, I’ve set a personal goal to get people to present at the conference who haven’t presented at a conference before. However, it can be intimidating to do a presentation in front of a bunch of people and I want to remove that barrier.

So, if you have something you want to share about Agile, even if you don’t think it’s enough to fill an hour presentation, let me know. Here are some ideas for ways to structure things:

• Interview Style: We work together to come up with a set of prepared questions that you’ll answer live — this works for people who find it easier to simply talk to and focus on a single person than an audience.
• Panel Discussion: If you have an interest in discussing and debating some aspect of Agile (e.g., Estimate or Not? Timeboxed Iteration or Not?, etc.), then we can put you on a panel with others. This works well if you don’t have anything specific in mind, but have opinions based on your experience.
• Standard Presentation: If you’re up for doing a presentation (from a 5-minute lightning talk to a full hour), we’re here to help you create that presentation, from outline to slide creation to coaching you on the talk itself.

Those are just some of the possibilities, I’m sure you can think of other ideas. The main thing is that you participate!

Questions? Comments? Want to jump in? Twitter (to @jitterted) is the best way to initiate a conversation, but I’ll also accept emails to tedyoung+sfagile at gmail.com.