What''s your developer productivity?
-
I've just been having a casual chat with a colleague about the number of objects (i.e. Tables, procs, functions, views, triggers, contraints, indexes) that we currently have in our SQL Server Data Warehouse application.
- It turns that a quick scan of sysobjects gives us in excess of 4000 objects. This breaks down as:
- Tables 665
- SPs 963
- Functions 94
- Views 280
- Triggers 65
- Constraints 964
- Indexes 375
- [The sharp-eyed/pedantic among you may realise that this isn't >4000 but these figures are from our live system and we've got alot of stuff waiting to go live that aren't included here!]
Given that the project has been going about a year and on average we have 2 developers at any one time that gives us an average developer productivity of approx 5 objects a day.
Is that good or bad? I haven't got a clue but it sounds quite impressive when you consider that a considered decent level of output from a traditional code-monkey is 10 lines of code a day (We have alot of procs and I would say all of them have more than 10 lines of code, alot of them have hundreds.).
[Admittedly a line of code in a traditional dev language is just that, a line of code whereas in T-SQL one SQL statement will typically be written over many lines. So, its impossible really to compare the two which is why I haven't considered the number of lines of code in our procs/functions.]
I'm interested to know what other people SQL Server developer productivity figures people are able to come up with based on the same criteria. It could make for an interesting comparison/conversation. If we get some interesting results from this I may even be tempted to collate them all and write a summary on it. Don't be telling porkies now
Even more interesting would be to, in a couple of year's time, compare these figures to an application built in Yukon to see if developer productivity really does increase which is one of the things Microsoft is going to be selling Yukon on.
Just spend a few minutes analysing this. It could make interesting reading.
Plus, if anyone's got any links to similar surveys like this I'd appreciate reading them.
Thanks!
Jamie Thomson
http://sqlblog.com/blogs/jamie_thomson -
In our home grown OMS (1 developer for 1.5 years) we have the following statistics:
23 Triggers
159 Tables
175 Views
222 Procedures
22 Foreign Key Constraints
13 Functions
118 Constraints/Indexes
126 Primary Keys
and a Visual Basic Front End with
20,359 lines
807 Comment Lines
comprising
981 Procedures for 1720 controls.
This was also done during a system conversion of 68 separate SQL Server 7 databases (upgrades from Access database systems) to a single WMS system.
Yes, it has been a long 1.5 years
If the phone doesn't ring...It's me.
-
I have no idea of the stats for all the work I have done because a lot of objects have been created and redesigned, sometimes there were new objects, sometimes consolidation of objects occurred. I currently am working on a system again which has grown from a small user app to a corporate database which also provides information external to the business. I would hazard that across the servers where my code is still running the total will easily cross 10,000 total objects and the lines of code will easily cross 250,000. But I will say it is not the amount of work done but the quality that is the key to anything.
For example in ASP
If X = Y Then
Response.Write "Yep"
End If
Will work just as good this way.
If X = Y Then Response.Write "Yep"
So 1 line instead of 3. And languages like C and Java can in essence exist as one line as long the all the right ; are in place. But we choose to wrap and tabbify it for looks and readability.
I will say ignore the amount of work, look at the work's performance and use of resources to determine if it is good.
Just because I wrote 10,000 lines doesn't mean it will be great. What if I stated I could handle a maximum of 3 transactions per minute. Now some joe shmo comes along rewrites the code with 2,000 lines and states it will handle 5000 transactions per mintue. Obviously he did the better job.
-
Antares,
Exactly right, which is why I stated that we shouldn't be interested in lines of code. Also, I was only really referring to DB objects (which can be gotten from sysobjects), not application code. This is just a non-serious discussion - a bit of fun really.
Maybe I should add a disclaimer: The number of objects or lines of code should not be taken as an implication as to the quality thereof!
Jamie Thomson
http://sqlblog.com/blogs/jamie_thomson -
I completely agree, but do you have any way of producing metrics for your work? Accuracy of delivery? On Time delivery? Bug Fixes? etc?
If you do or know a good resource for measuring an internal development staff I would love to hear it.
As for lines of code not meaning anything I agree for another reason as well. There have often been times that I've struggled for hours over 2 - 3 lines of code that "should be" working but are not.
Again, if you know of a good way to measure development staff I am all ears..well eyes.
If the phone doesn't ring...It's me.
-
I think it will be really hard to measure this. Consider one developer working the whole year on a vital enterprise-wide app that will boost company's internal operations effectivity tremendously and another working on hundreds of small department-wide projects. Who is more productive? Who is "more worth" to the company? Or put it that way: You can measure quantity, but measuring quality is tricky.
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
At my company we typically measure productivity for developers as number of projects/reports/ad hoc/other developement tasks completed. On average we complete 3 tasks a day for each developer.
Just some input from a small midwest company, I think it can be interesting to see the demands from different company cultures.
-
How do you deal with complexity and size of task differences? The developer who completes 10 quick hit tasks will be more productive than the developer who completes 1 task that was very complex and larger. The executives at my company are really pushing me for measurables and I am completely at a loss on how to do it.
If the phone doesn't ring...It's me.
-
In our particular situation the complex projects are divided fairly evenly, so all in all it seems to average out. But then with this being a small company we can have more control to say, well that is a two week project, and as Dave has one already, give it to the other developer. Plus, the quick tasks are just assigned to "developers" not one in specific.
-
I bet it helps with burnout also.
-
This remainds me about a consulting occasion in which I had to redesign the work performed in three years. It took me 4 months and not because I was good, I have to admit that the others were really bad. The number of objects went actually down! and the complexity was balanced between Back and Front end, therefore objects on the back end are no meassure at all. To even make things even worse, today I use my own templates to generate close to 75% of middle tier and backend with a push of a button therefore I had to charge by project not hourly.
In my opinion is very very very .... did I say very?
complicated to determine efficiency on the development of one productJust my $0.02
* Noel
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply