DBAs vs Developers: A Sad Tale of Unnecessary Conflict

For many developers, does DBA really stand for Don't Bother Asking? David Poole thinks it is time to end the unnecessary conflict between developer and DBA, and explains how to deal professionally with the inevitable friction between development and operation activities in IT

DevOps, Continuous Delivery & Database Lifecycle Management
Culture and Organization


  • A sad tale of unnecessary conflict
  • The lessons
  • Concluding thoughts

A sad tale of unnecessary conflict

A recent editorial on Simple Talk described how a senior IT figure, midway through a presentation on Continuous Delivery, broke off, sighed and let loose a diatribe against DBAs, their attitudes and working practices and how they were a blocker to progress.

I abhor the behaviour that lead to the quip that DBA stands for “Don’t Bother Asking”. Such an acronym flies in the face of everything that events such as SQL BITS, sites such as www.sqlservercentral.com or www.simple-talk.com, and user groups seek to promote.

Not so long ago, when working as a DBA, I would have used these examples in defence of DBAs before giving an impassioned and well thought-out argument trying to put the case for the DBA. No doubt a member of the developer community would have risen to the challenge with an equally impassioned and well thought-out counter argument. Neither one of us concedes ground, both of us absolutely correct but both of us failing to resolve an ancient conflict.

Now I am in a more senior position I have a different perspective on this battle. I do not have all the answers but I should like to share some of the lessons I have more recently learnt as a slightly less impassioned observer.

The Lessons

Call out bad behaviour early …

No-one owns a monopoly on being a jerk though it hasn’t stopped a tiny minority from trying to obtain one!

With a dispassionate eye I can think of very few occasions when I witnessed either a developer or DBA deliberately being obstructive and unhelpful.

I have seen people on both sides whose passion for their chosen profession acts as a pair of blinkers to a wider perspective. I’m afraid I have to plead guilty to this.

Whether the behaviour is intended or not, the problem is that it can sow the seeds of discord and those seeds can grow like Knotweed, having a corrosive effect on the DB/Developer relationship.

In any case it is incumbent on all of us to calm things down; to help channel the passionate and be especially merciless with the protagonist of the wrong. Nip problems in the bud; don’t leave it for an annual performance review.

It’s not just a DBA/Developer thing

I found it tremendously exciting to enter the world of employment. My first pay cheque, my first car, and my first responsibilities. I also witnessed one hell of an argument between a salesman and a marketing executive. Given the creativity and verbal dexterity that these two business disciplines require, it was highly amusing right up until the point where it got just that little bit too heated.

I learnt that, in addition to dripping honey, a salesman tongue can also spit venom.

I can summarize the argument in the following sanitized statements: –

  • Salesman: You marketing types have no idea what it is like to face an actual customer. Your strategy is just not practical. I have to shift ‘x’ thousand units by the end of the month.
  • Marketeer: You salesmen just don’t see the bigger picture. Yes you can flog product ‘x’ like that today to meet some short term goal but that will scupper everything we are trying to do to build our brand and grow the market.

Now substitute a developer for the salesman and a DBA for the marketeer.

  • Developer: You DBAs have no idea what it is like to face an actual business user. Your approach is just not practical. I have to deliver a system with ‘x’ thousand lines of code by the end of the month.
  • DBA: You developers just don’t see the bigger picture. Yes you can hack the schema like that today to meet some short term goal but that will scupper everything we are trying to do to build the data asset and get long term value out of our data.

No-one else knows (or cares) what the fuss is about.

Before I witnessed the argument I hadn’t really understood that there were two separate business functions. “Sales” and “Marketing”. To me they were simply “SalesAndMarketing”. I dare say that many business people just see “IT” and not “Developers” and “DBAs” or indeed any of the other functional titles that are so important to us in the tribal world of IT.

What I do know is that the beam of benevolence from our commercial benefactors can change to a glare of malignancy when the delivery of their pet project is jeopardized by fractious infighting

The DBA/Developer conflict solves nothing, but can draw unwanted attention that rebounds on the protagonists.

Immaturity in governance causes friction.

No public organization has much leeway in its financial or trading conduct, or in the way that it manages the data related to it. The governance and stewardship of data should be part of normal day-to-day operation of any financially-responsible company. There should be specific roles that are tasked with ensuring that all requirements for security, audit, regulatory-compliance, and data-quality are met. This will include the management of data quality, metadata, and reference data.

If that does not sound like the organization you work for then you are not alone. I’m sure there are organizations who adopt all the practices required of a contemporary business, but I have never seen one.

The problems arise when the business expects the benefits of such robust organizational structure without that structure actually existing. In the absence of those structures the expectation is that these functions are just something DBAs do!

Although DBAs should play a part in data-governance processes, they are not at a level within the organization where they have a sufficiently broad view of all concerns that would be required to lead and enforce data governance with authority.

In the absence of a clear data-governance role within the organization, DBAs often find themselves with a vaguely-defined or assumed responsibility without the existence of authority or a clear mandate. Even worse, when DBAs attempt to fill this role they find their authority undermined by those very people who originally abdicated that responsibility; short-term goals of a more senior manager trump the governance process of the more junior role.

When a role is undermined, it has the corrosive effect of undermining the authority for those areas where that role has a legitimate mandate.

Talk to the right people

A conversation with the right person can resolve conflicts quickly and painlessly. Personally I have found that a lead developer is the best person to talk to. Just as with DBAs, the path to becoming a lead developer is not a short one. These positions are relatively senior within IT and are the product of hard won and often and bruising experience.

They are best able to describe what the problem really is from the developers’ perspective and have the maturity to listen to the other side of the argument.

When a lead developer asks for a compromise they have almost certainly considered a number of alternatives and their need is genuine.

The worst thing that a DBA can do is to argue with a team of developers. It can put the lead developer in an untenable position with two unpalatable alternatives

  • Does he back the DBA and lose face and authority with the team he is supposed to lead?
  • Is he forced to back his team and support a bad compromise?

If a conflict occurs during a meeting or daily stand-up, then by all means state your case but suggest that a more technical discussion take place in a less confrontational forum.

That isn’t to say that communication should only take place between DBAs and lead developers. The more that DBAs and developers interact with each other the better for all concerned. It is simply that there is occasional need for mediation and more senior roles have a wide enough perspective to fulfil that role.

Communication is everybody’s responsibility

If DBAs or developers find themselves under pressure, it is vitally important to let each other know that the pressure exists. I can think of one particular situation that, with the benefit of hindsight, two disciplines working together would have produced a better balanced and robust solution.

The situation I faced was where an e-commerce site suffered a ‘site-down event’ which had occurred because of a problem in the databases.

All DBAs were summoned to the board room and we were told in terms that would be recognised by anyone familiar with the gory bits of the Old Testament what would happen to us if such a situation ever occurred again.

We were told that no excuses would be tolerated and that we were to prevent such an occurrence by any means necessary. The steps we took were undoubtedly Draconian and caused resentment in the developer community. If we had explained that to the development community we could have had allies instead of creating adversaries.

I know that only the DBAs received the fire and brimstone treatment. Senior management were more interested in extermination rather than root cause analysis.

This leads us to lesson seven.

Conflict is inevitable, it’s how you handle it that counts

Conflict in this context simply means that the needs of the different disciplines pull them in different directions. This is simply a fact of life, so conflicts are inevitable but can be ameliorated by negotiating a mutually acceptable compromise.

In his book “The five dysfunctions of a team” Patrick Lenceoni had ‘fear and avoidance of conflict’ as one of the dysfunctions. His book is short and easy to read; I heartily recommend it.

We have to recognize that the perfect coding solution probably isn’t the best solution for the database and vice versa. When we feel passionately about a subject it is difficult to listen to another’s point of view but in order to resolve conflict it is vital that we do so.

Remember, you are not trying to win an argument; I must emphasize that you are trying to reach the best compromise that both parties can live with.

Functional silos create more problems than they solve

I believe strongly that the agile community have got it right. A multi-disciplined team is more effective than trying to get teams of specialists to work together.

Functional silos encourage separateness and not cohesiveness. My experience is that this separateness leads to a breakdown in communication which results in misunderstandings and conflict in the negative sense.

Each silo adopts defensive processes and functions to protect it from unwanted effects of external interactions. In total the effect is much like scar tissue. Instead of speed and suppleness, scar tissue gives restrictive movement and slow progress.

I believe the answer is to build cross-functional teams aligned to the products that the business sells. This should mean that the coordination between such teams is part of a commercial strategy and more likely to be coordinated at a more senior level within the organization.

Whether I am correct in my beliefs or not, I do know that a poor choice of borders leads to conflict.

I do not have a good answer for the case where the underpinning components of a system have grown in size and/or complexity to the stage where a specialist team is required to deal with that component. Perhaps such a case should be seen as an indicator that a system is due for a redesign and rewrite.

Developers make the best data zealots.

Nothing beats the zeal of the converted. The best thing that can happen to a DBA is to be assigned a developer to work on a data project downstream of point of data entry.

The mark of a convert is when they start to rant about the appalling data quality, how easy it would have been to prevent and how it is jeopardizing their deliverable.

Of course the counter to this is when a DBA realizes that source-control, continuous integration and test driven development techniques can be used to give more reliable and robust deployments.

Imagine a situation where a DBA will only practice test driven development on projects where developers are present, or where developers will only practice good data husbandry when a DBA is standing over them. Very little has been achieved in such a situation other than compliance.

When each discipline adopts and acts as a champion for the practices of the other then a business transformation has taken place. When transformation is achieved then heavy weight governance become unnecessary

Concluding thoughts

From experience I know that, when developers and DBAs work well together, they don’t just add to each other’s effectiveness; they multiply it.

If there is one overarching lesson that encapsulates the nine lessons I have outlined, it is to focus on communication. This is something that IT people in particular seem to find very hard. It is much easier to look inward than it is to reach outward.

I do wonder whether the consequence of this is that some of the features and facilities in the tools we use remain underutilized and underdeveloped. Friction between IT factions prevents a feature requiring cross-discipline engagement in order for the adoption of the tool to be successful and widespread.

  • Do DBAs avoid SQLCLR, source-control and test frameworks because they are a developer thing?
  • Do developers avoid tools like Service Broker because it is a database thing?

DevOps, Continuous Delivery & Database Lifecycle Management
Go to the Simple Talk library to find more articles, or visit www.red-gate.com/solutions for more information on the benefits of extending DevOps practices to SQL Server databases.

Tags: ,


  • Rate
    [Total: 1    Average: 5/5]
  • Anonymous

    We have a lot of friction between the DBAs and the developers and I believe that Microsoft has a large part to play in the antagonism. MS has different recommendations to those who handle their various products, or, at least, so it seems.

    As DBAs we are tasked with the efficient running of the system. We recommend that the developers run all code against the DB in stored procedures. Ah no, say the developers, we have been to lectures and Microsoft is heavily pushing Entity Framework, so all of our new code is in EF. Since they started with EF, if there are long running queries, we have to run Profiler to see what monstrosity of an SQL query is being run. Before we were able to get statistics on performance from SQL Server itself and we could tune SPs accordingly. With EF we have no chance. For the developers, it is all water under the bridge. They have something new to work on. We discovered recently that the reason for our 30+ deadlocks per day was due to EF setting the isolation level to serializable. We DBAs see no benefit to EF, but the developers love it. They can code so much more quickly.

    Another example is with GUIDs. For some reason they got it into their heads that being able to predict the next ID in the primary key from data within a webservice was such a serious security hole, that they were obliged to start changing the datatype of all primary keys in all tables from int/bigint to uniqueidentifier. It solves their predictability problem but no thought was given to the clustered indexes that they wanted to base on these 16-bit values nor to the massive increase in DB size.

    Another point of centention lies with data quality. When our DBs were designed, I wanted lots of default- and check-constraints in order to prevent garbage data entering the database. ‘No, no, no!’ said the developers. ‘There must be no business logic in the database’. ‘We will validate all data entering the system via the application. Besides the errors generated by constraints is only more (unnecessary) work for us.’. The developers are not the ones that have to clean up the data over time because fields that should be unique aren’t or fields that may only have one of 3 values have more.

    Or indexes, another bugbear. The developers have discovered the recommended index feature in SSMS. So now, for every stored procedure they create, they also create the recommended index and we DBA are left with a heavily-written-to table that has 9GB of data and 23Gb of indexes.

    I am strongly of the opinion that developers should not design databases. They should be given a ready-designed DB and let them work from that via stored procedures, so that we can do our jobs and they theirs.

  • callcopse

    Depends on circumstances
    We run with no DBA support at my shop – our DBA simply looks after backups and work on their own tasks e.g. SSIS packages. Devs are expected to do all the design work and all support. We do run the danger of being jack-of-all-trades but devs are mainly quite capable.

    With this in mind I can say that EF is perfectly viable as a solution. Of course there are some times where you need to use procs for efficiency – perhaps around 5-10% of queries. Otherwise maintaining the business logic in a single, well structured place has so many advantages over the bloated and hard to read procs I’m surprised anyone still advocates them for mindless tasks like drop-down source data or more complex multi-transaction logic.

    GUIDs as PKs though I think can be lost except for a few circumstances.

  • PG

    Crux of the matter
    "A multi-disciplined team is more effective than trying to get teams of specialists to work together."

    I think this sentence gets to the crux of the matter. The friction between DBAs and developers stems from the isolation of roles. Developers treat the database as a magic storage/retrieval system and DBAs treat the database as a holy relic.

    Once you have highly cross pollinated teams, a lot of this friction is reduced.

  • David Allen

    Friction results from mismatched processes too
    I like the tone of the article and the various ideas. As an experienced (former) manager, I observe similar sources of friction: 1) attitude, 2) personality, and 3) process.

    A small number of people are prone to fighting and blaming. These behaviors have to be weeded out, one way or the other. If these people cannot be persuaded to change their behavior they need to be persuaded to find another place to work. Their attitudes can poison the workplace for the majority who enjoy working with others. If left untreated, the chronic discord will drive away your best employees – the ones who want to work well with others.

    Even with people who have good intentions to collaborate, they forget that people are different and come at problems with different viewpoints. We took a Strengths Finders exercise together, and gained an appreciation for our innate differences. This helps us to be more tolerant when others take different approaches. It’s not because "they are stupid." It’s because they view the world differently. And with our collaborative attitude, we must bridge the gap.

    And finally, I’ve seen people who have mastered those social skills, still encounter conflict because they were marching to different orders. This requires managers and supervisors to re-engineer the processes they have designed to reduce conflict. For example, if a DBA team is just one big pool of people, always on support, how can they be expected to participate in quality planning and design activities at a pace and with a reliability that supports rapid development? Just when you need them, they are managing a crisis. The answer is properly staffing the DBA group and providing a rotation or other mechanism to allow DBAs to have "Development time" that is different from "support time" so that they can concentrate and participate. That’s merely one example of how a process can be designed to promote or reduce conflict. It works in the reverse direction too. Developers have to have a time when they are dedicated to support to do that well just as they need time dedicated to development.

  • Grant Fritchey

    Excellent Point
    "When each discipline adopts and acts as a champion for the practices of the other then a business transformation has taken place. "

    That is extremely well said and probably the most important point in the whole article. I think I might add that (with appropriate attribution of course) to some presentations I give on database deployments. Seriously, that’s awesome. Well done.

  • Robert young

    A bit too nice
    I put off commenting, since my initial reaction was kind of strong. Seems not so much, from reading the comments!

    So: the issue remains as it has for decades. Because coders existed before (relational) databases, they’ve always asserted their hegemony over the data. "It be mine".

    The RM says, "not so fast smarty pants".

    There is no compromise; either the engine manages the integrity of the data, or the client code does. (Well, the client code can duplicate the constraints from the schema on the client…) Code likes to silo itself with bespoke data, while the RM says, "I’ll give you all data, and make sure it’s correct at all times. All you need to do is ask for data, put it on the screen, wait for user input, send it to me, and I’ll tell you (and the user) whether it’s right or not." Leaving the coder with little to do but format screens. A robot could do that… wait, they do. Oops.

  • Seven24

    Are DBAs being replaced by DBEs?
    First, just as database zealots will say never to use surrogate keys of any kind, guids can work perfectly fine as PKs *if* you use sequential guids and there are many good reasons for using guids over identity values. If you are concerned with index size, you can create a separate key for the clustered key that is opaque to application code.

    Second, except in very large, relatively unchanging organizations, I’m not convinced as to the value of a DBA over a DBE (database engineer) that knows all the stuff that DBAs do and can help build solutions. An engineer is easier to integrate into an agile team than an administrator. Having the experience of both building and administering the solutions you build adds the ideal perspective IMO.

  • Dave.Poole

    Communication is the key
    I think a break down in communication has caused a lot of misconceptions and bad decisions made on bad assumptions.

    I see people parroting things that they have been told 2nd, 3rd…nth hand without ever having thought things through for themselves.

    Let us suppose you had a tool that could quantify in an instant what the impact of a schema change would be. Because it would be quantified you could build decision logic and automated processes surrounding the schema change and thereby achieve the agility that you seek.

    This is why metadata and data lineage is so important but I have yet to see anything or anyone doing this particularly well, or indeed at all.

    The perceived lack of agility of an RDBMS is often down to people having to consider the impact of the change on downstream systems and the delay involved in accommodating those changes. Deprecate a field on which a downstream system depends and descend into a world of pain. This pain doesn’t go away with a NOSQL solution either. If NOSQL is perceived to address the pain of schema changes then probably what is happening is that application developers have been given carte blanche to do whatever is necessary to support the front-end application and the responsibility for adjusting downstream systems belongs to someone else. Hardly a fair or equitable state of affairs.

    There are many changes that can be made in an RDBMS schema that are really cases of "so what". The trick is to know the criteria for a "so what" and the criteria for a WTF.

    If the requirement is flexibility at all costs then this means that the organisation has to validate that requirement against the cost of the impact on dependent systems. In some cases it may be able to design downstream systems on the expectation of attributes being optional or not available. In which case this has to be a recognised design principle

    What cannot happen is a business person in charge of a small fiefdom to make decisions in isolation to their benefit but to the detriment of their colleagues. They have the right to make those decisions only with the agreement of their business colleagues.

    When dealing with data there is a defined amount of pain. You can shift the burden of the pain to different places but you cannot eliminate the pain. If you think you can then you are deluding yourself. Where that pain lands should be answered by well informed business requirements. As Fred P Brooks wrote "there ain’t no silver bullet"

  • DeafProgrammer

    Governance ? Meta-Data ?
    Well written article. Governance and the Meta-Data are the major players of eliminating the "Unnecessary Conflict" within the organisation or company (Corporate Governance)

    Quite simple, conflict is inevitable. Both potentially functional and dysfunctional and must be managed to maximise its beneftis and minimise its potential damage to the organisation or company.

    Cheers 🙂

  • Anonymous 25 year DBA

    For the good of the system
    When developers, DBAs, testers, Customer Reps, and Project Leads all see each other as organs within the same body, then perhaps they will begin to work together properly. Our 10 human body systems work together by communicating messages through electrical and chemical methods. We need to understand and appreciate the vastly different purposes of each organ/job position and communicate only through messages.

    A DBA must guarantee schema changes are made in an evolutionary sequence while developers just deliver a snapshot exe.
    A DBA is concerned with data migration while develpers are just calling the black box.
    A DBA is concerned with physical resources and backups and recoverability while developers just want data stored and retrieved.

    I’ve read plenty of non-violent communication books and conflict resolution books to know that neither side gets their way as-is. The evolutionary result is that both groups need to grow/change and create a newer, more powerful set of messages between their two sub-systems to make both groups happy.

    My developers tell me, if I ever leave, they’re coming with me, so I must be doing something right.

  • Beatdown DBA

    I gave up, I recommend it.
    I’ve been a DBA for about 20 years now. For about 10 of those I tried very hard to stay on top of what each developer was trying to do, giving them advice which they sometimes followed, sometimes didn’t. I cared about trying to do the right thing all the time. Then my last couple of managers came from the developer world and all the checks that DBA’s provide were just out the window. I gave up. Now, I don’t care anymore. I honestly think the DBA is a job of the past. The developers know what they are trying to accomplish and so what if the field says Name and it contains a serial number, they know that, it was switched over in the last ‘upgrade’. Nobody was using that region field, we dropped it. And it’s endless, and if you care it drives you crazy, but if you let go then it doesn’t matter. And having let go, you now serve no purpose other than doing some of the less known menial stuff that somebody else can figure out. We DBA’s are dinosaurs and the asteroid has hit, were just wandering around looking for a good place to lay down and die.

  • Dave.Poole

    @Beatdown DBA
    Sadly this is all too familiar and as I said when governance is assumed to be part of the DBAs role without explicitly stating so and support from the powers that be then this is precisely what happens.
    The question is to whether the organisation as a whole endorses an "anything goes" attitude towards data.
    What will eventually happen is that the organisation will reach a level of maturity where they will start to want to get more out of their data. At which point the practises for which people are praised for today will quickly become unacceptable.

    Ultimately you, as a DBA, have a set of values. The organisation also has a set of values. It is clear from your description that in this case the two are irreconcilable and the clash is a source stress. Giving up is not the answer because giving up is extremely corrosive to your mental well being.
    If your values differ so greatly from those of your organisation that you cannot reconcile them then it is time to look for a position where this is not the case.

  • Anonymous

    I, too, gave up
    About 8 years ago, I was brought into a shop with 12 developers who needed a real DBA. They hadn’t had a dedicated DBA for about 1.5 years after the last one left, leaving developers responsible for their own database changes. Management decided they needed a real, seasoned DBA to come in and do what DBAs are supposed to do. After about a year of fighting, I called it quits. Half of the developers appreciated what I was trying to do, and the other half resented it, even though I was working very closely with them in a spirit of collaboration. Management, who brought me in specifically for this role, refused to back me when I tried to do just what they tasked me to do. I left for greener pastures, and haven’t been a DBA since.

  • Anonymous

    How about those in the middle?
    There is also a very big middle ground of SQL Analysts/MI Analysts/Reporting Analysts. I am one and the skills sit squarely in the middle which causes even more fun, especially when you know more than either


  • Anonymous

    Jack of all trades
    I started out as a developer and was converted to an accidental DBA out of necessity. I’ve lacked the formal training that the traditional DBA has probably received, but I’ve been working exclusively on the DB side for the past 8 years. I find that my past experience gives me great insight into the world of the developers, but my compromises would probably drive the traditional DBA up the wall. I’ve worked with a few traditional DBAs that make it impossible for developers to do their jobs…so they would always come to me for assistance.

    It is a difficult balancing act to know when and where to draw the line. Business will side with productivity over reliability 99% of the time…even if they won’t admit it. There isn’t much room for a purist in an agile environment.

  • KCV

    DBA vs Developers
    We have surely found and endless supply of idiots designing databses and other idiots criticising them. There are all levels of developers and DBA’s The more senior the DBA the less they want to educate or even deal with developers. Coincidentally these DBA’s are most prone to restrict developers from creating or maintaining databases. So, who should be blamed when the design is poor?

    Furthermore, poor, fair, better and best practices need to accomidate the solution. I’ve seen really cool dynamic SQL created from programs that absolutely could not be done from Stored procedures. A DBA might criticise this but has nothing to replace it with that maintains the functionality. THe DBA is still happy to restrict dynamic SQL use. Who is the idiot when the client receives reduced functionality?

  • Grant Fritchey

    Seniority and Constriction
    I’m not so sure about the more senior DBAs being more likely to want to shut everything down and educate no one. In fact, most of the more senior people I work with are the exact ones trying desperately to educate people rather than simply cut them off.

    This type of knee jerk "developers are right and DBAs are stupid and evil" is absolutely every bit as destructive to our working together as the "DBAs are right and developers are stupid and evil" point of view.

    Yes, developers focus is on change and speed. DBAs focus is on stability and reliability. Yes, those lead to conflict, inevitably. But that doesn’t mean either side is wrong and it doesn’t mean we can’t work together. But it has to be working together. Not "if you go away my life will be better" from either side.

  • Robert young

    A BBF You Can Rely On
    — Yes, developers focus is on change and speed. DBAs focus is on stability and reliability

    I’m not convinced that the dichotomy is apt. The easiest datastore to change is one that’s in Organic Normal Form: changes to tables are transparent to code disinterested in those changes. Code which requires those changes have to deal with them, in any case.

    Coders wedded to "Select * from Foo" and then gleaning the columns of interest on the client is the evil bit. Just like their granddaddies back in the COBOL/file days, the datastore is treated just as a lump of clay, to be made into a beautiful David by the code.

    When you have a datastore that’s, in extremis, just one infinite Excel spreadsheet of columns, then you get into much trouble. Change that "table" and all code has to be visited. Ugh.

  • Dave.Poole

    @Robert, The various NOSQL DBs allow the changes you describe without revisiting all the code.

    The issue they don’t address is when that data is required downstream of the immediate application. The vendors tend to talk about restful services and API calls in vague terms but shy away from addressing mass extraction requirements. That is someone else’s problem. WTF!?!?!?

    The more experienced are recognising that schema enforcement and versioning is actually a very good thing and for this Apache Avro and Thrift are useful. They allow each instance of the application to enforce the schema rather than the central database and also to deserialise objects from the NOSQL store.

    Again, the experienced amongst us know that there is a fixed number of pain points within any optimised application. You can choose to spread these evenly to get a solution, you can choose that parts of your solution will take a greater burden in order to lessen the burden on others. but what you can’t do is eliminate the pain points in that optimised application. For unoptimised (tech debt ridden) applications this rule doesn’t hold up as half the pain points are artificial.

    Apache Cassandra describes the infinite Excel spreadsheet

  • Anonymous

    Attitude is everything
    Whatever your role, developer or DBA, you need to work in partnership to make thing going further. Putting together the competencies make thing better.

    Attitude is everything!