SQLServerCentral / Editorials / SQLServerCentral.com / Fix v. Create / Latest Posts

RE: Fix v. Create

tabinsc — Mon, 27 Aug 2012 09:19:06 GMT

[quote]I've seen it too. And not because the programmers wanted it that way. It puts programmers in the position of suffering through a job that they want to love but can't afford to lose, or risk being fired when they speak up against it.[/quote]Talk about a rock and a hard place! I've known plenty of good programmers who were forced into that same situation, due to marketing deadlines that were set before IT even found out about the project.

RE: Fix v. Create

jbnv — Sat, 25 Aug 2012 09:29:35 GMT

[quote][b]Michael Valentine Jones (8/24/2012)[/b][hr]As I said, it was at a place where I worked, meaning it’s not where I work now and I don’t need advice on looking for a new job.I don't think they were planning to fail or do poorly. They just operated according to the demands of the business which set due dates without regard of resources, practicality, or anything else.However, I have seen this same anti-pattern so many times that I have come to view it as the default project life-cycle of the real world. Kind of a dirty secret that no one mentions while they pretend they are following traditional, structured, agile, lean, extreme, or some other methodology of the day.[/quote]I've seen it too. And not because the programmers wanted it that way. It puts programmers in the position of suffering through a job that they want to love but can't afford to lose, or risk being fired when they speak up against it.

RE: Fix v. Create

Wingenious — Fri, 24 Aug 2012 19:31:29 GMT

[quote][b]Carrie.Sim (8/24/2012)[/b][hr]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.[/quote]AMEN!

RE: Fix v. Create

Michael Valentine Jones — Fri, 24 Aug 2012 15:21:47 GMT

[quote][b]Miles Neale (8/24/2012)[/b][hr][quote][b]Michael Valentine Jones (8/24/2012)[/b][hr][quote][b]Miles Neale (8/24/2012)[/b][hr][quote][b]Michael Valentine Jones (8/24/2012)[/b][hr]Keep in mind the normal project life-cycle:1. Set the delivery date2. Throw some crap together.3. Test4. If testing is successful, then go live, otherwise go live.5. Define requirements.6. Go back to step 1.:crying:[/quote]Joke or the way you really see it?[/quote]I made this up as a joke at one place I worked, but I never heard anyone say that's not the way we do things.This is the "true" project life-cycle, as opposed to the one people claim to be following.[/quote]If this is the way it really is, you also may need to look for a better job where better things are done better. Slapdash is not excellence. I know that tho "a program be but three lines long, someday it will have to be maintained". But to work in a shop that plans to fail as you define the process is to work with failure as your goal. Where is pride in your work if you strive only to do poorly? As a joke I find it funny, as a possible truism I find it not so.[/quote]As I said, it was at a place where I worked, meaning it’s not where I work now and I don’t need advice on looking for a new job.I don't think they were planning to fail or do poorly. They just operated according to the demands of the business which set due dates without regard of resources, practicality, or anything else.However, I have seen this same anti-pattern so many times that I have come to view it as the default project life-cycle of the real world. Kind of a dirty secret that no one mentions while they pretend they are following traditional, structured, agile, lean, extreme, or some other methodology of the day."I've found out why people laugh. They laugh because it hurts so much… because it's the only thing that'll make it stop hurting."Stranger In A Strange Land by Robert A. Heinlein

RE: Fix v. Create

Miles Neale — Fri, 24 Aug 2012 14:52:51 GMT

[quote][b]Michael Valentine Jones (8/24/2012)[/b][hr][quote][b]Miles Neale (8/24/2012)[/b][hr][quote][b]Michael Valentine Jones (8/24/2012)[/b][hr]Keep in mind the normal project life-cycle:1. Set the delivery date2. Throw some crap together.3. Test4. If testing is successful, then go live, otherwise go live.5. Define requirements.6. Go back to step 1.:crying:[/quote]Joke or the way you really see it?[/quote]I made this up as a joke at one place I worked, but I never heard anyone say that's not the way we do things.This is the "true" project life-cycle, as opposed to the one people claim to be following.[/quote]If this is the way it really is, you also may need to look for a better job where better things are done better. Slapdash is not excellence. I know that tho "a program be but three lines long, someday it will have to be maintained". But to work in a shop that plans to fail as you define the process is to work with failure as your goal. Where is pride in your work if you strive only to do poorly? As a joke I find it funny, as a possible truism I find it not so.

RE: Fix v. Create

Eric M Russell — Fri, 24 Aug 2012 14:43:01 GMT

Most of my work could the classified as "refactoring". It's often intended to fix some issue in an existing database system (like performance optimization, auditing, or parallelizing a data load that was previously run sequentially), but it also involves implementing new procedures, SSIS packages, tables, etc. as well.

RE: Fix v. Create

Michael Valentine Jones — Fri, 24 Aug 2012 14:25:01 GMT

[quote][b]Miles Neale (8/24/2012)[/b][hr][quote][b]Michael Valentine Jones (8/24/2012)[/b][hr]Keep in mind the normal project life-cycle:1. Set the delivery date2. Throw some crap together.3. Test4. If testing is successful, then go live, otherwise go live.5. Define requirements.6. Go back to step 1.:crying:[/quote]Joke or the way you really see it?[/quote]I made this up as a joke at one place I worked, but I never heard anyone say that's not the way we do things.This is the "true" project life-cycle, as opposed to the one people claim to be following.

RE: Fix v. Create

Eric M Russell — Fri, 24 Aug 2012 14:20:04 GMT

[quote]Are you more of a craftsman that develops new widgets for your clients to use, or are you the handyman, repairing and improving things that weren't built well enough the first time. [/quote]Well, let's put it another way: Are we the consultant / contractor who develops new widgets for our clients to use, or are we the staff developer, repairing and improving things that weren't built well enough by the contractor the first time.That's more like it.:-D

RE: Fix v. Create

Miles Neale — Fri, 24 Aug 2012 14:14:44 GMT

[quote][b]Michael Valentine Jones (8/24/2012)[/b][hr]Keep in mind the normal project life-cycle:1. Set the delivery date2. Throw some crap together.3. Test4. If testing is successful, then go live, otherwise go live.5. Define requirements.6. Go back to step 1.:crying:[/quote]Joke or the way you really see it?

RE: Fix v. Create

Michael Valentine Jones — Fri, 24 Aug 2012 13:29:18 GMT

Keep in mind the normal project life-cycle:1. Set the delivery date2. Throw some crap together.3. Test4. If testing is successful, then go live, otherwise go live.5. Define requirements.6. Go back to step 1.:crying:

RE: Fix v. Create

jbnv — Fri, 24 Aug 2012 13:05:49 GMT

Fix versus create? In my experience, more like plan, implement infrastructure, create, test, correct, tune. And the sum of the percentages is more than 100%. (At least that's the impression I got from my previous employer.)

RE: Fix v. Create

TravisDBA — Fri, 24 Aug 2012 11:13:10 GMT

In the immortal words of Dennis Ritchie "I fix things now and then...":-D

RE: Fix v. Create

Miles Neale — Fri, 24 Aug 2012 10:08:30 GMT

I started over 40 years ago working on bugs and for the first year I was the typical 90/10. But things changed. Since year one I have written new code, architected new solutions, designed new systems, redeveloped from old systems in to complete new rehosted or redeveloped systems, and maintained little. I have lived on the cutting edge from time to time and have written for numerous platforms and in a very diverse collection of languages. Well designed and architected tested solutions are the goal, and if done well systems can last for elongated periods of time without maintenance. Some of the solutions I developed ran for over two decades, most of the time without error and being enhanced only as the business required it. If time and care is taken in the design, development, and testing the result has a chance of being a lasting solution. Without a commitment to excellence the software and process requires much care and feeding, maintenance.M.

RE: Fix v. Create

MdApache — Fri, 24 Aug 2012 09:36:05 GMT

I would estimate that most of my time is 80/20 on fixing/new. As I have moved up in my career and into management roles, I stress to my employees that my PRIMARY concern with code that they write is that it MUST be easy to troubleshoot and debug. I consider this more important than any other coding factor. The OO or "fill in the latest programming craze" zealots are the worst when it comes to this. I have seen relatively simple programs overcomplicated to the point that they are almost impossible to follow or understand. Have a simple rule that your code must be easy to troubleshoot and debug leads to good decisions about the program architecture and techniques. It also encourages liberal commenting.

RE: Fix v. Create

Rod at work — Fri, 24 Aug 2012 09:14:43 GMT

For me, it is overwhelmingly in favor of "Fix".

RE: Fix v. Create

F. Dwarf — Fri, 24 Aug 2012 09:13:45 GMT

In my current job I went from a 90%/10% fix/mantain ratio to 5%/95%I consider myself good at troubleshooting and tuning, those are the parts of my job that I enjoy the most. The problem is that the better I do those two, the less I have to work and I tend ot get bored and look for another job that would keep me busy. That has not happened with my current employer though.I see myself as a problem solver, and I think I do a pretty bad job at creating new stuff (from design to code and test).

RE: Fix v. Create

GSquared — Fri, 24 Aug 2012 09:02:37 GMT

I'd add one more category to that: Prevent.I spend a significant amount of my time making it so I won't have to fix things in the future.

RE: Fix v. Create

Michael Valentine Jones — Fri, 24 Aug 2012 08:58:56 GMT

[quote][b]Question Guy (8/24/2012)[/b]...on some of the reports, the values are hard coded, and don't actually show the real values...why...because the real values are not actually saved to the database...[/quote]I'll bet that saved a lot of time during development.

RE: Fix v. Create

Question Guy — Fri, 24 Aug 2012 08:53:51 GMT

I've been programming for over 10 years...and now I have finally seen it all...I just inhereted an application that was apporved(and in use) for production(developed by a vendor)...one problem...on some of the reports, the values are hard coded, and don't actually show the real values...why...because the real values are not actually saved to the database.....FAIL.But like I always say.... HERE I COME TO SAVE THE DAY!!!!!!!!!!!!!!!!!!!!!!!!!!

RE: Fix v. Create

nelsonj-902869 — Fri, 24 Aug 2012 08:40:50 GMT

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:

RE: Fix v. Create

MSorteberg — Fri, 24 Aug 2012 08:38:38 GMT

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".

RE: Fix v. Create

Carrie.Sim — Fri, 24 Aug 2012 08:38:36 GMT

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.

RE: Fix v. Create

j_e_o — Fri, 24 Aug 2012 08:38:22 GMT

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.

RE: Fix v. Create

Michael Valentine Jones — Fri, 24 Aug 2012 07:34:52 GMT

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.

RE: Fix v. Create

hisakimatama — Fri, 24 Aug 2012 07:24:08 GMT

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 [i]how[/i] 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 :-)

RE: Fix v. Create

Joe Johnson-482549 — Fri, 24 Aug 2012 07:05:13 GMT

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.

RE: Fix v. Create

chrisn-585491 — Fri, 24 Aug 2012 06:57:26 GMT

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.

RE: Fix v. Create

OCTom — Fri, 24 Aug 2012 06:37:55 GMT

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.

RE: Fix v. Create

asdawkins — Fri, 24 Aug 2012 05:07:12 GMT

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

RE: Fix v. Create

Knut Boehnert — Fri, 24 Aug 2012 05:05:18 GMT

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. ;-)

RE: Fix v. Create

Nakul Vachhrajani — Fri, 24 Aug 2012 04:00:53 GMT

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.

RE: Fix v. Create

paul.knibbs — Fri, 24 Aug 2012 03:17:35 GMT

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.

RE: Fix v. Create

C64DBA — Thu, 23 Aug 2012 23:35:44 GMT

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.

Fix v. Create

Steve Jones - SSC Editor — Thu, 23 Aug 2012 22:02:58 GMT

Comments posted to this topic are about the item [B]Fix v. Create[/B]