Some time ago our squad manager recommended to all of us to read a book Lean UX: Applying Lean Principles to Improve User Experience. Not only he recommended this book, but he actually delivered a copy to each of us! So, with all my you-know-how-I-am-about-paper-books – I had to read it! And now I would encourage everybody to take a look at this book (it’s really short , too:))

I an not going to try to retell it in my blog; as I’ve mentioned, it’s probably easier and faster to read it. But I want to emphasis a couple of things, which I really liked about this book, and to share some of my thoughts in connection with it.

Here are some principles of SO development, mentioned in the book, which I find really important:

–Seeking constant feedback from the user, prototyping, showing the results, making changes, showing results again. I always believed, that this is the most important part of the SO development – to find out, what the users really want. And sometimes they are not even sure, what they want, and you need to ask right questions, to make them to realize, what they really want. And I still remember, how miserable I was on one of my previous jobs, when I was not allowed to talk to the end users, “because they are stupid, and do not know what they want”…

– Not striving for the perfect solution “on the first try”, but rather approximating, and changing design based on the user’s feedback. This is a very sensitive subject, because, as it was noted decades ago in the classic book by Weinberg – “The Psychology of Computer Programming”, programmers tend to view the critiques of their programs very personally :).

– “No heroes” approach. This is a very important concept, and I wish more people would realize it. Quite often people believe, that there is a limited number of “heroes”, who know, how to program “right”, and who can save the world. And that only geniuses make a difference in the world of SO development. And do not take me wrong, there is nothing bad in being a hero:). The problems begin, as the authors of the book point out correctly, when the “heroes” can’t work well in the team and when they can’t share their knowledge and techniques.

The question I’ve being asking myself while reading this book is. how all these principles can be applied to the database development. Through the whole book, although the authors talk about cross-functional team and about the fact that everybody should participate in the design sessions and other discussions, they do not really mention database developers. Meanwhile, you can hardly imagine any application these days, which would not interact with some database. And when we have a database, we immediately have to take into account, that database objects 1) are “more permanent objects” 2) most likely are used by different applications 3) are harder to modify, and their modification requires coordination between different applications.

Very often the database developers are convinced, that “this is not for us”. And yes, theoretically we would love to be able to perform more extensive analysis of all our data needs before we start prototyping, we would love not to rush – but we can’t! What we as professionals need to realize is that either we will become fast and flexible, or the application developers will proceed without us, creating such monsters as our “default rules hash”, when a big chunk of data is stored … in a Ruby model! I still firmly believe that this design disaster happened because n application developer got really tired of fruitless attempts to get a db dev review approving the changes he needed!

So – how database development can be Lean? How it can be Agile? The key is to use more database functions along with packages and procedures, when available. They can be modified as fast as an application code. In many cases no further database objects changes will be requires, in other cases we can change database objects later, after the “database interface” is changed. And what is more important – they can be changed independently.