How do you go about adding a small addition to a big system?

[cs.punk]

I'm curious to how you tackle adding 'small/medium' additions to an existing system that you are not familiar with.

Do you try to write code as soon as possible and start debuging your way from there? Or do you spend a lengthy amount of time first analyzing how the system works and then take it from there?

 

I usually try the former approach but it's tempting to just write code that'll get the job 'done' somewhat and fix any major issues, this however doesn't guarantee it's secured and doesn't have any hiccups when used in a obscure way. 

 

Cheers

[requinix]

Or do you spend a lengthy amount of time first analyzing how the system works and then take it from there?

I do that. I would rather get it right, in basically every sense of the word, than spend my time fighting with something because I don't know how it works. There's a huge risk of doing something which seems correct only to discover hidden problems later. (Which is basically what you've pointed out.)

In general I don't write code that I can't stand behind. It's got my name on it: it damn well better be good quality. [edit] I dub this the Showtime Rotisserie programming style. [/edit]

 

I could write a long diatribe about how the code-it-first-fix-it-later programmers really grind my gears but I need to get to sleep and I can't do that if I'm riled up. The short version is that (I feel that) programmers who jump into code without knowing what they're doing are the ones who give PHP a bad name, and I wish they would all burn their computers, burn whatever crappy "certificates" they have in lieu of actual knowledge, recant all the stupid "advice" they've given to unsuspecting saps on the Internet, and never go back to programming ever again.

 

(Disclaimer: the above does not apply to anybody I know here)

 

Oh. And realize that spending more time learning stuff now means less time learning stuff later. Odds are you won't be doing just one little thing now only to never touch it again, right?

[cs.punk]

 

Oh. And realize that spending more time learning stuff now means less time learning stuff later. Odds are you won't be doing just one little thing now only to never touch it again, right?

 

I'd hope so. Past work hasn't really gone further on for me. Perhaps it's directly due to later bugs being found, directly being my fault.

 

And I definitely agree with you however I'm doing low budget projects and it seems even the client is encouraging a 'it works 90% of the time' using '50% of the effort'. Guess I just hang in here until I start getting more structured systems to work on.

[ignace]

Well I think it all depends. If the code is properly written and somewhat documented. Analyzing first, is a good approach (if this is the case, see below the --). However what are the chances, right?

 

I have edited quite a few legacy systems, some of which you could not tell the difference between if the code was obfuscated first and then checked in, or just written like that.

 

When you have to deal with a system where the typical variable name does not exceed one alphabet character, and function names describe their functionality as well as a 3-year old describes their toys. I highly recommend you code first, ask questions later. Followed by at least a few days of intensive testing, be sure to involve as many people as possible, and fix the bugs that apply to your code, put any other bugs you find in their bug tracking software (if they have that sort of thing).

 

--

 

In a good case scenario there are some things you must do before you can even consider starting implementation. Fix bugs! If there are already multiple open bugs for the part of the system you are going to be editing, then it goes without saying that whatever you are going to do is going to make it worse. Probably what has been happening to you. If they apply unit-testing, your job is even easier to squash bugs!

 

Done fixing bugs? But still not too comfortable? Refactor! Some functions body you will be using exceeds your screen height? Good candidate for refactoring! Break it up into smaller functions (literally copy-pasting parts of the parent function into the smaller function and resolving any missing local variables). If they apply unit-testing, again your job will be much easier.

 

By now you will feel as if you wrote the damn thing.

[ignace]

it works 90% of the time' using '50% of the effort

 

That is not specific to your client. That is how every businessman thinks: cut costs wherever possible while maintaining the same level of quality. It's probably because you allow this kind of pressure from the client (do it faster!) get the better of you and rack up bugs faster than a rotting body. Trust me, I've been there cutting corners everywhere I could to meet an impossible deadline and still be fixing bugs while the client was on his way to celebrate the release of his software... Get out of it before it puts you out!

 

If they do not hire you afterwards because of the potential cost, it's at least that: cost, not the blame of possible incompetence, not implying you are here, which is devastating for your career.

 

That said, it are though times, which is probably why you get no repeat business.

[xyph]

ignace hit the nail on the head. I've done a few hack-together budget jobs, got the client to help me test, and even had some repeat business that way. I'm very vocal about it being the wrong way and warn about potential future problems, but they still choose the cheap route.

 

If it's financially possible, it's definitely better to understand before modifying. It's rare you'll find a client/manager that is ready to pay for that, though

[Philip]

I could write a long diatribe about how the code-it-first-fix-it-later programmers really grind my gears

I agree, and sadly I have to do that a lot more for work than I'd like because of deadlines (something I have very little control over.) That's a rant for another day though

 

But yes, analyze then fix is the way to go when you have the appropriate amount of time. And if you don't have the appropriate amount of time, push for more time.

[thehippy]

I would just like to thank all the programmers out there that write tests for their code.  I think its only happened two or three times now with medium to large existing applications, but to get a job to work on that's actually been unit tested is near bliss.  To me well written tests are better than external documentation, better than autogenerated documentation, each test is a usage case that show me the previous coder's intent, damn near priceless.