August 23, 2012 at 10:02 pm
Comments posted to this topic are about the item Fix v. Create
August 23, 2012 at 11:35 pm
I have recently moved to a job where I am expected to refactor a substantial part of the code base, particulary around BI. This is new work, altough I have to document the old system along the way. Before this job however, I spent about 5 years about 90/10 in maintenance/new work. I have to say though, I like the challenge of creating new systems.
August 24, 2012 at 3:17 am
Steve Jones, 2012:
"The more I think about my career, the more I think that I've spent more time fixing things than actually working on new code."
Maurice Wilkes, 1949:
"As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs."
So, you're not the first to come to this realisation! 😉
I tend not to be involved too much in debugging SQL myself, but that's mainly because the developers of our main application work at a remote site and look after their own data. Most I've done has been to add some indexes to speed up commonly used queries.
August 24, 2012 at 4:00 am
For the better part of my career till date, I was working on sustenance assignments. These assignments required me to fix bugs in an application that was 10years old. Then, as parts of the application started to be re-engineered, I was pulled into cleaning-up old code and now finally, I am into developing newer areas of the application. In short, for me, it has been 80% sustenance, 20% new development.
Thanks & Regards,
Nakul Vachhrajani.
http://nakulvachhrajani.com
Follow me on
Twitter: @sqltwins
August 24, 2012 at 5:05 am
For the last five years it was more like 95/5 maintenance to new development due me supporting a well established system.
However this has changed now that we moved to a new platform, upgraded software and re-developing our ETL layer. Currently it is 70/30 with spikes of 10/90 at days.
Quite interesting to get a new system rolling and trying not to implement too many bugs to find later. 😉
August 24, 2012 at 5:07 am
My client doesn't always no it, but I do spend quite a lot of time thinking of the best solution to a problem and sometimes I feel bad that they actually pay for that time. But thinking on the maintenance time I safe them, I do not feel bad at all. I am priviledged to spend more time designing new processes.
I would say 50/50.
The maintenance 50% is mostly working on other people's poor designs.
Raphael
August 24, 2012 at 6:37 am
I don't know if you'd call it fixing but I spend quite a bit of time making changes to enhance functionality; functionality that was not in the original design but someone came up with later.
Actually fixing something has been on the decline and I find myself working on new development about 60% of the time.
August 24, 2012 at 6:57 am
I spend most of my time fixing other peoples data/code. 50% of my work load would be reduced if people would give a $h!t, follow simple instructions or at least get some elementary training. It's to the point that I consider my current role to be buggy like one of the responders suggested to the original poster and I'm currently studying and networking to get some relief elsewhere. My current shop would score a 1 on the Joel test. Other than that, I like refactoring and maintaining code.
August 24, 2012 at 7:05 am
For the last couple of years, my job function has only been to implement new large projects. However, I still spend 10-20% fixing issues on old code as we are implementing.
August 24, 2012 at 7:24 am
Hm. I'd say I have about a 70/30 split of maintenance to development. At my workplace, all of the business tools in use were coded by the company's first programmer, who left earlier this year. Since the company needed a programmer suddenly, they simply asked him to learn how to code on the job, and from there he developed the programs to run most of the operations here; however, since he was essentially an amateur programmer, there's quite a few design flaws.
The biggest problem is that he didn't future-proof anything he coded, though it's understandable, as he probably didn't know how to future-proof as it was. As such, I spend a good bit of time refactoring his code and making sure it can work with our migration of data from Microsoft Access to SQL Server. In some cases, this is rather unpleasant; the C# interface that runs most of the basic tasks for the business is about 30,000 lines of code, and there's two comment "blocks" (just a sentence each!) in the whole thing. Figuring out exactly what he coded and how it works is... Complicated, at best. Especially when he used the oh-so-fun naming convention with object b having property a, and so forth, so large stretches of code turn out to be just random mishmashes of single characters. Rather tough to handle at times, but I've managed decently so far 🙂
- 😀
August 24, 2012 at 7:34 am
I think most maintenance is actually new development activity that was skipped during initial development because the developer was in a hurry, under pressure, incompetent, lazy, etc.
In particular, design review and detailed testing are often skipped, so the problems don't emerge until the application is in production.
It’s far more time-consuming to fix a bug that's in production and design errors, especially database design errors, can take a tremendous effort to fix, so that leads to the 90/10 maintenance/new split.
August 24, 2012 at 8:38 am
We just completed an Agile project that overall took about 18 months. We had maybe a couple dozen bugs during that time (some of those were really changes in requirements). Test driven development (unit test first!) coupled with automated subsystem testing really keeps the bugs down.
The effort was not trivial and was a true multitier application.
This project had 4 SCRUM teams spread across two continents and three time zones.
The breakdown was roughly 90% on new code and 10% fixing issues.
August 24, 2012 at 8:38 am
Software development for me is an art. It needs experience architect with hand-on and practical experience to design an efficient database access. But, most of the time, a lot of peoples started with coding directly, because he/she not able to think ahead,plan or imagine the scope in future.
Sometime/most of the time, the scope of the system and requirements also changing from time to time. Beside we have very experience Business System Analyst.
Therefore, why we need to spend more time in maintenence, it boiled down lack of experience and critical thinking leader, architect, system analyst.
August 24, 2012 at 8:38 am
As a Business Intelligence developer I could be working in any of 4 environments, i.e. SSIS, SSAS, SSRS or Dashboards. In my case I am primarily on the latter three so a vast majority of my time is creation. Every once and a while I might be asked to help out on the SSIS side of things but that, as I said is rare. So, I spend probably 90% of my time creating and 10% "fixing". And, sometimes, as a report goes through different iterations - I am asked to make changes/improvements to that report - so the "creating" and "fixing" sometimes gets mingled together. Now, the other members of my team that work primarily in the SSIS area of our business. They are probably just the opposite. They are constantly/often "fixing" problems with data or the flow in one way or another - and doing little creation. I'd say they are doing about 80% "fixing" and 20% "creating".
August 24, 2012 at 8:40 am
A good Friday topic.
In my current 'Apps team' position, I not only provide SQL support for 8 hardware servers, 8 VM servers and the major applications that may reside on them, but I also support Crystal Reports (Business Objects Enterprise), Access 03/07/10 and a tiny bit of VB.net on Vis Studio 2008.
Fortunately, the SQL side of tasks is mainly server support, maintaining backups, SQL Agent jobs, etc which is an ongoing every morning 15 to 45 minute review. I handle all upgrades for the apps that reside on my servers (maintenance or development?) and have had a big one (not a critical one) going on for about 6 months that because it isn't critical, always seems to get pushed to the back burner when something else jumps up as a perceived crisis.
Then there are the frantic calls from Crystal or Access users asking for assistance with a new/old report or getting a query to do this. Finally there are the VB.net projects that I get to chose, as we have old legacy VB6 code that needs to be updated. I would consider this to be new development work as I'm discovering that VB6 code DOES NOT automatically translate over to VB.Net...much to my chagrin. What fun! I'd say my load is 95/5 on the maintenance/repair/fix this side of the coin.:w00t:
Viewing 15 posts - 1 through 15 (of 33 total)
You must be logged in to reply to this topic. Login to reply