Martin Fowler and No DBA
by John Turner
Posted on March 04, 2013
Last week, [Martin Fowler](http://martinfowler.com published an interesting post that discussed the role of a DBA in the context of NoSQL databases. Interestingly he titled this post No DBA
Martin’s post couples the role of the DBA to that of Integration Databases. Today’s wisdom would suggest that integration databases are almost always a bad choice for enterprise application integration because database changes have to be negotiated by a number of groups (application teams and the DBA) and evolution of relational schema is very difficult to achieve effectively.
Application teams circumvent this ceremony by using schema-less NoSQL databases and message based application integration.
So does this suggest that the DBA is almost always a bad choice? I don’t think that this is what Martin is suggesting but one phrase he used struck me. He stated that “I often hear complaints about change orders that take weeks to add a column to a database. For modern application developers, used to short-cycle evolutionary design, such ceremony is too slow, not to mention too annoying.”. I think this ceremony is indicative of the culture that all to often exists within DBA groups. This culture can also exist in architecture, testing and yes, even development groups.
While this is probably over simplistic, this culture and ceremony often has sound reasoning for why it was in place at some point in time. However, all too often these groups have been incentivised in a way that causes friction between them i.e. they have not been incentivised to achieve the same end.
We have seen solutions to this before where testers come together to work within a team to improve quality. Over time this removes the ‘quality police’ mentality and testers are incentivised to work with the team to improve quality. Emergent design has had a similar impact in forcing architects and development teams to work together. So, if we are not saying that DBA’s are just a bad idea perhaps the answer is to embed them in development teams and incentivise them to the same end.
One thing that this all ignores is the need for the DBA community to get on board with the process and technology shift that has happened over the past 10 years. Not an easy nut to crack given that the adoption of Agile requires the circumvention of the ceremony held sacred by the DBA.
Here are a couple of other interesting references:
Marissa Mayer ends Work From Home
by John Turner
Posted on February 26, 2013
This morning I was interested to read that Marissa Mayer would end the Yahoo policy of allowing people to work from home. It appears that some Yahoo workers were able to work from home exclusively while others could spend varying amounts of time working between home and the office. There was also a period of time in which relocations and outsourcing further distributed the Yahoo workforce.
What surprised me about this is the weight of opinion that opposed this move and the feeling that it was counter productive. I think the reason it was such a surprise is that for the past 10 years there has been an up swell of opinion that the “power of team” was all important.
The entire Agile movement is based on bringing multidisciplinary teams together to work toward a common goal. Similarly, DevOps advocates shared goals and tight feedback loops between development and operations teams (depending on your view). In fact, most argue that not only should teams work from the same office but in table clusters that facilitate low cost but rich communication and knowledge dissemination via osmosis.
To achieve this rich collaboration and communication is a prerequisite. Face to face communication is the richest form of communication and as you move toward asynchronous communication such as email you might argue that you are not collaborating at all (you are just exchanging separate and distinct views).
You might also argue that IM, Video conference etc facilitate rich communication but the reality is that while it provides richer communication nothing beats face to face.
So then we have the water cooler effect. This is the effect of people discussing (or overhearing) conversations that they may never have in the normal course of their work. There is lots of analysis of the value of the water cooler effect so I won’t rehash it but suffice is to say that this goes out the window when you’re working from home.
I’ll finish this with a quote from Ryunosuke Satoro:
Individually, we are one drop. Together, we are an ocean.
Can we be together when some are at home, some are in the office, some are in offices far afield, some are in a different time zone etc? Even in today’s fully connected society I think the answer is no.
Lies, Damned Lies, and Statistics
by John Turner
Posted on February 24, 2013
Reading a post by Patrick Kua on An Appropriate Use of Metrics got me thinking about the type of statistics and metrics I have seen organisations use and the naive way in which they can be interpreted.
Using inappropriate metrics is lazy at best!
The very first example Patrick used was one related to the focus on bugs raised in production. Focusing purely on metrics led to the decision to work harder to close bugs that are raised but generated little insight into the underlying causes of those bugs. Were they caused by poorly defined requirements? Were they caused by poor development practices? Are they really bugs that are being raised or just poor understanding of the product features? A bit more insight might have highlighted that they were as a result of poor user understanding of the product so it would have been better to focus on user awareness of designing intuitive user interfaces.
Patrick goes on to say:
Organizations love metrics because it makes setting targets easier, and discourages people from questioning the goal behind the target. This leads managers into a false sense of organizational efficiency. Strong incentives tied to strong metrics force people to concentrate on just one part of the work, neglecting other contributing factors that might make a goal more successful.
This sort of lazy, dumbed down, manage by numbers approach is why many organisations are run by those pesky accountants!!
Read More8th Light - The Principles of Craftsmanship
by John Turner
Posted on February 18, 2013
On Wednesday, in conjunction with Skills Matter, Paddy Power are hosting a talk by Bob Martin on ‘Components and Architecture’ (if you are in Dublin drop in!). This prompted a colleague to read some of Bob’s recent ramblings which brought him to a company called 8th Light. He forwarded a very interesting post on ‘The Principles of Craftsmanship.
During its conception, the founders of 8th Light ‘wanted to build a community of professionals who believed in their core that the best way to build software was to build it well.’ This led them to declare that they are principled and subsequently identify what those principles were. I’ve repeated them below:
Read MoreWhy the Centre of your Application is NOT the Database
by John Turner
Posted on February 15, 2013
When you attend a user group at Skills Matter you are offered a complementary copy of the Open Source Journal (OSJ). Having recently finished reading ‘NoSQL Distilled’ a feature article by Bob Martin leap at me from the front cover of the OSJ. In this article titled [No DB](http://blog.8thlight.com/uncle-bob/2012/05/15/NODB.html, Bob discussed the dominance of the relational database and the disruption caused by the emergence of NoSQL databases in the first decade of the 21st century.
Bob’s tale of how he was coerced onto using a relational database by marketing is one that resonates with me. How often are technical solutions chosen to placate one person or another? In Bob’s example the pressure was applied by marketing because they felt it was what their customers wanted.
Of course, vendors are skilled and motivated to apply their own coercion techniques to force technology decisions. Naive organisations ill equipped to properly manage vendor engagements often find themselves making poor decisions because vendors have ‘created internal champions’ through corporate hospitality or miss sold to decision makers who do not perform appropriate due diligence for one reason or another. Irresponsible decision makers also use vendors to allow them to to abdicate responsibility by providing a direction in which they can point should things not go to plan. But I digress.
Bob recalled the days in which people were encouraged to encode their business rules into stored procedures thus creating a high cost of migration to another vendor (another yacht Larry? Surely not!). But then “Finally, someone realised that there might just be some systems in the world that did not require a big, fat, horky, slow, expensive, bodily effluent, memory hog of a relational database!”. I don’t know what ‘horky’ means but right on brother!!
What Bob is saying is that this should not be a priority when designing your application. Your application use cases should be front and centre and database and frameworks should be down in the detail. How do you argue with that? I felt that a natural progression was to consider domain driven design (DDD), a technique that puts the domain model a the centre of your application but this is not explicitly mentioned by Bob. I wonder if this is intentional?