Category Archives: books

I haven’t being posting anything forever, but now I am going to fix this, and planning to write about all the interesting things in the World of Data on a more regular basis. And I am going to start (or rather resume) by writing about the book I read recently – the book which totally blew my mind!

The book is called Managing Time in Relational Databases: How to Design, Update and Query Temporal Data, and it presents the most complete bi-temporal data model. Actually, you may call it “tri-temporal”, because in the “classic” bi-temporal model you have an “effective” time and a “system time”, and the system time just indicates, when the record was added or updated.

However, in the model which is described in this book – Asserted Versioning – an additional concept , assert time , is introduced. That is, “the time we believe(d) it was true”.

Let me tell you, that I was a biggest fan of Richard Snodgrass temporal database concepts probably since the time they were first published (or something close to that :)). I really “felt” them, and since I can’t remember when, I really wanted to implement them – in the real life, in some real project.

I can’t even say that nobody ever needed the temporal data. It’s just for some reason people strongly believe that storing changes is very resource consuming. Which is not exactly true. As the authors of this book point out, it’s way easier to convince your manager to store one year worth of transactional log than to store the objects versions for the same period of time, although the latter requires way less space and is way easier to use. I was constantly have a hard time convincing people that 1) versioning is not so space -consuming, 2) you need to have both start and end date, not just the start date 3) the “current” state is not the one which has end date IS NULL, but the one having end date=INFINITY, and the list can go on and on….

This being said, the book feels extremely refreshing. It just so clear what the authors are trying to achieve, I understand each and single statement completely, I do not need to go through all the examples to understand the concepts…

Now more than ever I really-really – really wish… I could implement it somewhere in the real life 🙂

 

Advertisements

Leave a comment

December 4, 2015 · 6:19 pm

12 essential skills – Leadership

Now I finally finished the book I was talking about for several times already – “12 essential skills of software architect”. And now I am even more confident, that all IT people should read this book, not only the people who want to become software architects.  Because communication is not the strongest point of most of IT people.

The Chapter 4 of this book talks about leadership, and I would like to share some quotes, which precede this chapter:

Management is doing things right; leadership is doing the right things
– Peter F. Drucker, Father of Modern Management.

Leadership os the art of getting someone else to do something you want done because he wants to do it.
– Dwight D. Eisenhower

And one more quote from Eisenhower, which I love so much – I put it in my signature on Enova mail:

You don’t lead by hitting people over the head; this is an assault, not leadership.

Leave a comment

Filed under books

How to say “yes” and “no” – part one

For a while now I’ve being reading a great book – “12 Essential Skills for Software Architects” by Dave Hendricksen.

This book is really-really awesome, and I am going to write about it in more details, but today I want to talk about one very important topics, touched in this book: how to talk with people. By people I mean our co-workers, our teammates, our managers and our customers.

We often tend to just “speak our mind”. Straight. And it does not necessarily end well. Because – you remember? – a person you are talking to will get only approximately 20% percent of it, by “get” I mean, (s)he will understand it the way you intended things to be understood. And very often these 20% won’t be the ones you think are the most important. So quite often, when you are trying to say: “let’s make this piece of code better!” you are heard like “you do not know how to code!” You see some problems with the suggested design, and you respond: no, this is not going to work! You need to change it! And the only thing which happens – you put you opponent into defensive mode.

Meanwhile, you can always say exactly what you want, just using slightly different words. For example, something like this: I am not sure I like an idea of adding this column… I think, it may cause some problems in X and Y situations. What do you think? I was wondering, whether we could consider Z instead. May be, we can experiment and return to this discussion in a week?

This way you didn’t offend anybody, and people are actually willing to listen to your advice. I love the quote from the above book:

If you wish to make a man your enemy, tell him simply, “You are wrong”. This method works every time.

… to be continued

Leave a comment

Filed under books

Thinking about the books I read, and redefining the role of database developers

Right now I am reading the book “Agile Samurai”, which many of you have read already. I’ve already covered about 60%  of the book, and since my team has being agile for a while I do not expect any big surprises in the rest of it. I am not saying, that reading this book is useless, it’s just that I think I can share some thoughts about it, even although I am not completely through.

All these books which I recently read: Team Geek, Lean UX and now Agile Samurai talk essentially about the same concept: about not spending too much time on documentation, because it’s impossible to document everything before the actual work starts, about getting constant feedback from the customer, about being a team player, about willing to redo the work over and over, and other related things. Which is all understandable, however I keep thinking  about the role of the database developer in this process, and how everything related to the database can fit into this technology.

The special role of the database is, and always will be to be a shared piece between different applications and at the same time to be an application of it’s own. And because if it’s dual nature there will be pieces of work which can’t be done in small increments. As my husband put it, when we were discussing this issue: you can’t fly an airplane in small increments, you need to left the whole thing in the air at once.

SOmetimes I am not sure, whether this is completely understood by Agile Masters :). In the Agile Samurai book one of the conversations between the Master and the Student is exactly about building the Data Warehourse, and the Master is quite clear about it. On one hand, he is saying that it is possible you won’t be able to deliver something in each iteration, on the other hand, he states, it’s bad. At some point you can’t help but wondering, whether all customers have ADD and just can’t wait?!

I remember how almost a year ago I was reading the Agile Database Development site, and found out, that everything what mentioned there was only a half-solution this way or the other. If you search for “Agile Database Development” on the web, you will find a lot of papers and presentations, but when you start reading them – it’s just Git, pgTAP, etc., but not really development technique….

For the past couple of weeks I am thinking a lot about the ways to actually make database development agile, to classify different types of database development, to identify, what agile means for all of them (mostly I am talking about database design vs. database functions and packages development, but not only that). I know, that 1) the quality of the database design can’t be compromised 2) we still should be ready to make design changes at virtually any time 3) or work around them 4) by means of creating functions and utilizing our super-natural optimization skills 🙂

… as the book says, “I will reflect more on this”.

Leave a comment

Filed under books, Data management, Systems

Lean UX: Book review

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.

And I am going to write more about this:)

Leave a comment

Filed under books, Systems, Team and teamwork

Team Geek – a book review

I’ve recently finished reading a book Team Geek: A Software Developer’s Guide to Working Well with Others. This book was originally recommended to me by one of my co-workers, who made a short presentations about it during one of our “Buzzes”. So I’ve got a Kindle edition of it, but it took me a while to actually read it.

And I am glad I finally did it – liked this book a lot. What’s interesting, it talks about many things we recently implemented in our company, and in our squad in particular, and it made me to appreciate even more what our squad manager is doing. For example, the book tell how important is to keep the scrums short, so that they would remain real “stand-ups”. And I know that some other squads had grown into a habit to have their scrums like 30 minutes long or more. I now, that the members of those squads hate it. Originally I was not to say upset, but wondering, why our manager insists on all of us really standing during the scrum,  why he stops discussion about particular issues and says – we will discuss it after the scrum. But now I see, that those were right things to do. There are also other things from this book, which we do in our squad, like the way we track the issues.

But what I liked the most, was the fact, that the book is actually about how to work with people, how to work in  teams in the IT industry. And I can’t think of a more important topic. In the very first chapter of the book the authors say that the myths usually attribute development of some systems or products to a single person, like Linus is often thought of as a person, who single-handedly created Linux. But:

Actually Linus  just wrote  the beginnings of a proof-of concept Unix-like kernel, and showed it to an email list. <..> Linux is hundred times bigger than that and was developed by hundreds of smart people. Linus’s real achievement was to lead these people and coordinate their work.

The time of “single geniuses” is over, if there ever was one on the first place. And these days nobody is going to tolerate a difficult person just because of his or her individual abilities. It’s not worth if, if the person can’t work with others.

The book is full of excellent examples of how important it is to develop team, to develop team culture. I especially like how the team culture is compared to the yeast in a bread dough: if we have a right starter, the team culture will be preserved, even when none of the original team members will be there.  Another important chapter id the one which talks about the managerial skills, “even if you think you do not want to be a manager ever”.

Overall I think it’s a great book, which helps you to understand “how it all works”, and I strongly recommend it.

And it’s not that long at all 🙂 🙂 🙂

 

Leave a comment

Filed under books, Team and teamwork