June 12, 2014 at 7:39 am
Ed Wagner (6/12/2014)
I find the most conflict occurs when determining user requirements. The business side doesn't know what they want because the client doesn't know what they want.
The curse we all suffer! If they don't really know what they want then how can you be expected to give it to them? The majority of the time this situation is caused by bad project managers. There are very few who are good at what they do and fewer still who seem to understand the importance of specs. Instead you get to do the work of creating something and they "run it by the user". This goes on and on and eventually the result is something that has nothing to do with the original request. Go do that with a plastic surgeon, a home builder, a carpenter. That doesn't work out, but for some reason it is normal in software.
Cheers
June 12, 2014 at 7:58 am
hakim.ali (6/12/2014)
A few days ago, there was an editorial on SSC about the DBA being too large/encompassing a term (http://www.sqlservercentral.com/articles/terminology/109566/). It led to a very interesting discussion (http://www.sqlservercentral.com/Forums/Topic1577204-3554-1.aspx). One of the topics discussed was that of a database developer. I happen to be this kind of animal, that bridges the gap between development and DB administration. I live in both worlds, and I think roles like mine help resolve the issues this editorial discusses.I do not know how many companies still have firmly entrenched developers and DBAs in us-vs-them style camps. Most places I have worked at have had good collaboration if not outright intermixing (Agile teams with 2 devs, a DBA/database developer, and a QA). Places that continue to tolerate/promote the divide are only hurting themselves.
At a recent client one team had all the power. The other team was a third class citizen. Somehow a test team had so much kudos too (I could only see greasy pole climbing reasons). One of the most unhappy and unproductive places I have worked at. Everyone was busy. Everyone was producing things. Everything was of a poor standard. Everyone was miserable.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
June 12, 2014 at 8:07 am
I work in a very small shop. I have to wear both the DBA hat and the developer hat. So for me, there's no conflict. However I do wonder about the emergence of ORM's like the entity framework, especially with it's code first design pattern. Basically it allows the developer to create tables at the instantiation of a project. In small shops I think that might work, but because I also design tables, views, SP's, etc. I prefer the idea of designing the database first, before doing the application. I always work by designing the data first, then move outward from there.
Rod
June 12, 2014 at 8:17 am
Alas most of the failed and failing projects I have worked on have all been in recent years. But we are getting off topic the DBA v the developers is the topic. Many years back on a large integration project the teams where divided into functional v migration. There was much conflict between the teams but the more experienced members tried to build bridges with the poorer members causing conflict for it's own sake. The conflict was never resolved but left to simmer, it did cost timewise a considerable amount. It would have been better to be addressed by good management.
On another project many years later we had conflict between 4 different teams but when spotted by a clever project manager it was resolved early. Whilst I couldn't quantify the cost I can tell you resolving the issue early made a massive difference to the motivation, thanks to Mike Howarth.
Ignore conflict and it will cause you very costly problems later on.
June 12, 2014 at 8:37 am
I don't ever like to hear speculation about whether the DBA or programmer needs to fix something. My answer to this debate is simple: If you claim it, then show me the metrics. Let's also review the SQL code that is executing. It isn't all that hard to insert the ability to log all SQL queries at their start and end as well as all important units of code that can be switched on an off at the app level. That gives an immediate picture of whether to refactor app code, refactor the SQL code, optimize the database, or restructure how the data is being stored and accessed.
Regarding the debate about using stored procs and Entity Framework: Every programmer should understand SQL and manually review all generating SQL queries. It isn't hard to put in logging that grabs generated queries when certain thresholds are crossed. It's up to the CIO/CTO to put in a good framework and pattern that is documented, enforced and effective at logging these kinds of things for review and monitoring. That is a management and policy issue. The leadership needs to make sure that there are appropriate resources invested continuously to handle this. If they don't, then development and forward momentum becomes harder and slower as time goes on.
That said SQL is archaic. If you step back from what you are used to, it is ridiculous that we need to optimize databases and manually decide on where to put data (on what disk should this table or portion of data live). The SQL instance is already seeing the requests coming in and the frequency. It should be aware enough of itself to make decisions about how to manage the physical hardware resources and organization of underlying data for itself.
For flat queries, EF works great with stored procs and I use them where appropriate. But what am I supposed to do when I have large amounts of data that require server side paging with user defined, multi-column sorting with dynamic search terms? And even worse, what am I supposed to do when those results map to relational objects that are also returned? It's a shame SQL hasn't addressed the issues that LINQ expressions a EF have. SQL has no means to easily tell a stored procedure about dynamic sorting with server side paging and optionally included sub results (essentially dynamic joins). LINQ and EF handle this really well. The thing that tells me that SQL needs a rethink is to review the generated SQL that is our LINQ and EF create to achieve this. It's chunky because SQL gives no better option to query code. The SQL code "advances" made in 20 years have not been anywhere near the level of advances that have been seen in other coding languages.
Clouds and hybrid solutions that are coming out for data storage and retrieval are definitely advancing. Our organization now has a policy of writing all applications to be totally agnostic of the underlying data store. We can use SQL, NoSQL, local databases, WCF, SOAP, rest API's, could services or hybrid data stores to get and save our data. The data storage and retrieval code can be totally changed out using IOC and dependency injection without ever changing the core application code, UI or business logic. The point of this is that we are "detaching" ourselves from direct reliance on in-house SQL databases.
Best,
John
June 12, 2014 at 8:43 am
[p]I am having some difficulty understanding the categorizations of roles used here.
[/p][p]My understanding of a database administration role is close to Wikipedia's, where a DBA looks after but does not design databases (which I think logically is a development function).[/p][p]The term "developer" here seems to be used as a synonym for "software application developer", or even "programmer". However, I guess that the role covering the design of a database and the creation of the objects (stored procedures, user defined functions, views and so forth) in a data access or abstraction layer is that of a database developer (who, if using SQL Server will have to be fluent in some, but not all, parts of T-SQL (DDL and DML respectively).[/p][p]I believe my own role to be that of a web and database developer, joining two disciplines.[/p][p]Somebody may have a job title of "Database Administrator" but if they also create databases (tables, relationships) then that is database development. Isn't it?[/p]
June 12, 2014 at 8:58 am
The way I see it: the application is like the busboy, waiter, and Maitre d', while the the database is like the chef.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 12, 2014 at 9:00 am
I work in a very small shop. I have to wear both the DBA hat and the developer hat. So for me, there's no conflict. However I do wonder about the emergence of ORM's like the entity framework, especially with it's code first design pattern. Basically it allows the developer to create tables at the instantiation of a project. In small shops I think that might work, but because I also design tables, views, SP's, etc. I prefer the idea of designing the database first, before doing the application. I always work by designing the data first, then move outward from there.
I am currently working on a project that uses Entity Framework Code first and I am not impressed. I recently saw a table that had a field that should be NVARCHAR(25) instead of NVARCHAR(5) so I changed it. Ten minutes later the developer called asking if I had done anything because the application was crashing (this was in DEV environment). What I found was that when you use the Code First process, any change to a bound field that is not implemented by the application will cause the application to crash! WTH???
June 12, 2014 at 9:00 am
Tavis Reddick (6/12/2014)
[p]I am having some difficulty understanding the categorizations of roles used here.[/p][p]My understanding of a database administration role is close to Wikipedia's, where a DBA looks after but does not design databases (which I think logically is a development function).[/p][p]The term "developer" here seems to be used as a synonym for "software application developer", or even "programmer". However, I guess that the role covering the design of a database and the creation of the objects (stored procedures, user defined functions, views and so forth) in a data access or abstraction layer is that of a database developer (who, if using SQL Server will have to be fluent in some, but not all, parts of T-SQL (DDL and DML respectively).[/p][p]I believe my own role to be that of a web and database developer, joining two disciplines.[/p][p]Somebody may have a job title of "Database Administrator" but if they also create databases (tables, relationships) then that is database development. Isn't it?[/p]
A DBA that does not contribute to the design and implementation of their database is not much value to the company. To my mind, a DBA should take full responsibility for the correctness, efficiency and reliability of all aspects of their database. This means taking full responsibility for the design and implementation of everything from server hardware through database schema, up to and including the stored procedure interface.
Simon
June 12, 2014 at 9:13 am
In my experience, if you are charged with "maintaining" something then you typically will want to have a say in it's design. Many good DBA's are very involved about how data is structured during the design phase. This has to do with sharding data and partitioning large tables, as well as the design, review and performance testing of the most significant queries. It's almost impossible to maintain something that is poorly designed. In some organizations all a DBA might do is watch and optimize indexes, manage backups, optimize storage, manage and audit access, etc.
It's also difficult to be a good database designer if you are not going to be the person maintaining the databases down the line. You need the experience of seeing what happens as things get filled with lots of data and are intensely used. Because of that, I often think of the database architect and database developer as being closely tied to, if not the same person as the DBA who will maintain the data.
June 12, 2014 at 9:27 am
simon.crick (6/12/2014)
Tavis Reddick (6/12/2014)
[p]I am having some difficulty understanding the categorizations of roles used here.[/p][p]My understanding of a database administration role is close to Wikipedia's, where a DBA looks after but does not design databases (which I think logically is a development function).[/p][p]The term "developer" here seems to be used as a synonym for "software application developer", or even "programmer". However, I guess that the role covering the design of a database and the creation of the objects (stored procedures, user defined functions, views and so forth) in a data access or abstraction layer is that of a database developer (who, if using SQL Server will have to be fluent in some, but not all, parts of T-SQL (DDL and DML respectively).[/p][p]I believe my own role to be that of a web and database developer, joining two disciplines.[/p][p]Somebody may have a job title of "Database Administrator" but if they also create databases (tables, relationships) then that is database development. Isn't it?[/p]
A DBA that does not contribute to the design and implementation of their database is not much value to the company. To my mind, a DBA should take full responsibility for the correctness, efficiency and reliability of all aspects of their database. This means taking full responsibility for the design and implementation of everything from server hardware through database schema, up to and including the stored procedure interface.
Simon
Right or wrong, a lot of companies do not agree with you on the design issue.
Cheers
June 12, 2014 at 9:36 am
There some right idiots out there managing IT departments, one of the reasons for all the current failing projects. It used to be that design was a slow process factoring in all requirements from functional to scalable, maintenace and future proofing. These days it's all about getting the existing known functionality delivered as quickly as possible. This then means future change can be a nightmare and where the conflict between the DBA and the developers can be intensified.
June 12, 2014 at 9:38 am
jfogel (6/12/2014)
simon.crick (6/12/2014)
Tavis Reddick (6/12/2014)
[p]I am having some difficulty understanding the categorizations of roles used here.[/p][p]My understanding of a database administration role is close to Wikipedia's, where a DBA looks after but does not design databases (which I think logically is a development function).[/p][p]The term "developer" here seems to be used as a synonym for "software application developer", or even "programmer". However, I guess that the role covering the design of a database and the creation of the objects (stored procedures, user defined functions, views and so forth) in a data access or abstraction layer is that of a database developer (who, if using SQL Server will have to be fluent in some, but not all, parts of T-SQL (DDL and DML respectively).[/p][p]I believe my own role to be that of a web and database developer, joining two disciplines.[/p][p]Somebody may have a job title of "Database Administrator" but if they also create databases (tables, relationships) then that is database development. Isn't it?[/p]
A DBA that does not contribute to the design and implementation of their database is not much value to the company. To my mind, a DBA should take full responsibility for the correctness, efficiency and reliability of all aspects of their database. This means taking full responsibility for the design and implementation of everything from server hardware through database schema, up to and including the stored procedure interface.
Simon
Right or wrong, a lot of companies do not agree with you on the design issue.
Some DBA's inherit a database that was designed and implemented before they joined the company, but there's something seriously wrong if the DBA is not involved in any new design work that takes place after they join the company.
June 12, 2014 at 9:49 am
simon.crick (6/12/2014)
jfogel (6/12/2014)
simon.crick (6/12/2014)
Tavis Reddick (6/12/2014)
[p]I am having some difficulty understanding the categorizations of roles used here.[/p][p]My understanding of a database administration role is close to Wikipedia's, where a DBA looks after but does not design databases (which I think logically is a development function).[/p][p]The term "developer" here seems to be used as a synonym for "software application developer", or even "programmer". However, I guess that the role covering the design of a database and the creation of the objects (stored procedures, user defined functions, views and so forth) in a data access or abstraction layer is that of a database developer (who, if using SQL Server will have to be fluent in some, but not all, parts of T-SQL (DDL and DML respectively).[/p][p]I believe my own role to be that of a web and database developer, joining two disciplines.[/p][p]Somebody may have a job title of "Database Administrator" but if they also create databases (tables, relationships) then that is database development. Isn't it?[/p]
A DBA that does not contribute to the design and implementation of their database is not much value to the company. To my mind, a DBA should take full responsibility for the correctness, efficiency and reliability of all aspects of their database. This means taking full responsibility for the design and implementation of everything from server hardware through database schema, up to and including the stored procedure interface.
Simon
Right or wrong, a lot of companies do not agree with you on the design issue.
Some DBA's inherit a database that was designed and implemented before they joined the company, but there's something seriously wrong if the DBA is not involved in any new design work that takes place after they join the company.
Maybe there's a different kind of DBA needed, the Database Architect.
Most times if developers (specially application developers) are left to the design of the database, it will cause problems due to a poor DB design. DB design is a complex task that most people won't do correctly, even "experienced" DBAs.
June 12, 2014 at 9:58 am
Simon,
It isn't that I do not agree with you, but not involving the DBA is somewhat common. At best those companies have a database designer on staff, but that is unusual. Years ago I went round and round with developers from BEA over this kind of stuff. They gave me no say in much of anything and yet complained about why they couldn't use more than one "long" column in a table. Gee, maybe because a long in Java isn't the same as it is within Oracle? That project failed.
Cheers
Viewing 15 posts - 31 through 45 (of 79 total)
You must be logged in to reply to this topic. Login to reply