August 24, 2012 at 8:53 am
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!!!!!!!!!!!!!!!!!!!!!!!!!!
August 24, 2012 at 8:58 am
Question Guy (8/24/2012)
...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...
I'll bet that saved a lot of time during development.
August 24, 2012 at 9:02 am
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.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
August 24, 2012 at 9:13 am
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).
August 24, 2012 at 9:36 am
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.
August 24, 2012 at 10:08 am
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.
Not all gray hairs are Dinosaurs!
August 24, 2012 at 11:13 am
In the immortal words of Dennis Ritchie "I fix things now and then...":-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
August 24, 2012 at 1:05 pm
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.)
Jay Bienvenu | http://bienv.com | http://twitter.com/jbnv
August 24, 2012 at 1:29 pm
Keep in mind the normal project life-cycle:
1. Set the delivery date
2. Throw some crap together.
3. Test
4. If testing is successful, then go live, otherwise go live.
5. Define requirements.
6. Go back to step 1.
:crying:
August 24, 2012 at 2:14 pm
Michael Valentine Jones (8/24/2012)
Keep in mind the normal project life-cycle:1. Set the delivery date
2. Throw some crap together.
3. Test
4. If testing is successful, then go live, otherwise go live.
5. Define requirements.
6. Go back to step 1.
:crying:
Joke or the way you really see it?
Not all gray hairs are Dinosaurs!
August 24, 2012 at 2:20 pm
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.
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.
😀
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 24, 2012 at 2:25 pm
Miles Neale (8/24/2012)
Michael Valentine Jones (8/24/2012)
Keep in mind the normal project life-cycle:1. Set the delivery date
2. Throw some crap together.
3. Test
4. If testing is successful, then go live, otherwise go live.
5. Define requirements.
6. Go back to step 1.
:crying:
Joke or the way you really see it?
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.
August 24, 2012 at 2:43 pm
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.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 24, 2012 at 2:52 pm
Michael Valentine Jones (8/24/2012)
Miles Neale (8/24/2012)
Michael Valentine Jones (8/24/2012)
Keep in mind the normal project life-cycle:1. Set the delivery date
2. Throw some crap together.
3. Test
4. If testing is successful, then go live, otherwise go live.
5. Define requirements.
6. Go back to step 1.:crying:
Joke or the way you really see it?
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.
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.
Not all gray hairs are Dinosaurs!
Viewing 15 posts - 16 through 30 (of 33 total)
You must be logged in to reply to this topic. Login to reply