"Previous" developers - the bigger picture

[Andrew Snow]

In my RoRo travels, I've been initiator of, the recipient of, and privy
to, disparaging remarks about "the previous bunch of n00bs" who were the
last developers to touch a project.

This happens on projects big and small, by both professionals of many
years experience, all the way down to non-Rails shops who slapped a
junior coder on the project.

But because you don't know the circumstances:
* the budget
* the deadlines
* politics
* promises and obligations
* vague scope
* creeping scope, etc
I think it unwise to pass judgment on the "previous guy", whether to the
client, or to your peers.

Indeed, it would be bad form for the "previous guy" to mention any of
the above, especially if he parted company with the client in awkward
circumstances. Comments on the previous guy doesn't really give the
client the warm fuzzies anyway.

TLDR; Lets not rip on each other. Lets keep these thoughts to ourselves
and stick to doing what we do best.

- Andrew

[Marc]

Well said. ❤

 

[Daniel Draper]

Andrew, I totally agree. My comments were not meant to be disparaging to any individual. They were meant as a lighthearted poke - and directed at a group more so than any one individual.

I sincerely apologise, once again for an oversight in judgement.

- Andrew

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
To post to this group, send email to rails-...@googlegroups.com.
To unsubscribe from this group, send email to rails-oceania+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.

--
Daniel Draper
CEO (Code Executive Officer),
Codefire

www.codefire.com

Mobile: +61 403 089 661
Aus: +61 8 7127 6740
US: +1 (408) 217-1859

AppLaunch | Rescue Ops | Integrate

[Andrew Snow]

On 20/06/12 12:52, Daniel Draper wrote:
> Andrew, I totally agree. My comments were not meant to be disparaging to
> any individual. They were meant as a lighthearted poke - and directed at
> a group more so than any one individual.

Cool -- this wasn't specifically at you, I wanted to address the topic
generally as it has been bugging me for a while. And I've been guilty
of it in the past!

- Andrew

[Korny Sietsma]

I've definitely been there - brought in on a "rescue project" at a large Australian business, called in to take over after a bunch of "cowboy coders" had failed to meet a project milestone.  The key proof of their being cowboys was that they'd used Star Trek characters as the names for a bunch of their packages - there was the Uhura module and the Khan module and the like (this was back in Java land).  I remember lots of people shaking their heads at the terrible system they'd been building.

Fast-forward a couple of months, and it became apparent to me that while the guys we replaced were definitely a bit amateurish, most of the genuine problems in their code were probably in the end caused by the culture of the client company, which was pretty poisonous*.  The Star Trek package names were a bit foolish, but seemed far more like a way for frustrated people to let off steam, than a smoking gun proving these guys were rank amateurs.

I never really got proof one way or the other of whether the original developers were "n00bs" or not; certainly they didn't have any sort of decent tests :)  But I was a bit ashamed at going along with blaming them for all the project problems, accepting without skepticism that they must have been to blame, when obviously a big chunk of the blame lay with the client as well.

- Korny

*One example: half way through the project their Enterprise Architecture group, who had never met with anyone from our team, decided to globally ban the Spring framework, because one of them had read that it was all about aspect-oriented programming, and that was a dangerous thing.  (This was around 2005? or so - when Spring was definitely mature and accepted all around the Java world).  From

- Andrew

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
To post to this group, send email to rails-...@googlegroups.com.
To unsubscribe from this group, send email to rails-oceania+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.

--
Kornelis Sietsma  korny at my surname dot com http://korny.info
"We do not quit playing because we grow old, we grow old because we quit playing" - O.W. Holmes

[Rufus Post]

This is why we have the term "past me" to refer to that "other developer" who looks and talks exactly like you but cannot possibly be you because the code is so smell.

It's respectful to only invoke the term "past me", "past you" is considered impolite.

Mother Rufus

--

You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.

To post to this group, send email to rails-...@googlegroups.com.

To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.

[Michael Pearson]

On Wed, Jun 20, 2012 at 12:44 PM, Andrew Snow <and...@modulus.org> wrote:

But because you don't know the circumstances:
 * the budget
 * the deadlines
 * politics
 * promises and obligations
 * vague scope
 * creeping scope, etc
I think it unwise to pass judgment on the "previous guy", whether to the client, or to your peers.

 

I've been thinking about this for a while, as recently I've been subjected to a similar situation. Formerly I agreed 100% with the above, and haven't wanted to cast character judgements based on bad code, especially as it's often the result of somebody coming from Perl or PHP and having to learn RoR without help.

However, I've seen several examples where the only explanation could be deliberate laziness or native lack of ability, not inexperience or pressure.

I've met developers who, despite years of experience in a multitude of roles, can't understand the very basics of how to program in a consistent and maintainable manner. I've met other developers who are skilled (or have the potential to be) but approach every problem with a "let the next guy deal with it" attitude.

What I've found separates these guys from the simply inexperienced or over-stressed is a signposting. A # TODO or # XXX goes a long way towards explaining the intent of 'bad' code and giving a future maintainer and understanding of why it's there and what will happen if it gets rewritten.

--
Michael Pearson

[Kirill Radzikhovskyy]

+1

On 20 June 2012 12:44, Andrew Snow <and...@modulus.org> wrote:

- Andrew

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
To post to this group, send email to rails-...@googlegroups.com.

To unsubscribe from this group, send email to rails-oceania+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.

--

FreeBSD is for those who love UNIX(tm).
Linux is for those who hate Windows(tm).

"To recurse is human, to box a continuation into an object and send it across a network is divine. "
-- Andy Kitchen

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

-- Brian W. Kernighan.

[Dave Burt]

The experience of coming across some code with a view to
maintaining/modifying it, having uncharitable thoughts about the guy
who coded it, then realizing part-way through the work that the guy
was that infamous jerk "past me", is rather sobering. Sometimes the
"previous guy" just wasn't as experienced as one is now.

Have you had an experience like that?

Dave Burt

[Yasith Fernando]

Happens all the time to me when i am refactoring code that i wrote months ago.

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
To post to this group, send email to rails-...@googlegroups.com.

To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.

--

Yasith

W: http://blog.thekindof.me/

[Andrew Stone]

Yeah, I write tests so I can understand my own junk two weeks later. ;D

On 20/06/2012, at 5:41 PM, Yasith Fernando <yas...@gmail.com> wrote. 

[Enrico Teotti]

I agree with what you say Andrew, and there is no point in playing the
blame game.

But I reckon it's really valuable to both developers and stakeholders
to identify the reasons why a project is in a poor state.

I really don't like the "it's nobody's fault" approach.

Cheers,
Enrico

Enrico Teotti
Software development and web design
currently working @ http://abc.com.au
Sydney, NSW, Australia
enrico...@gmail.com
mobile (AU) +00610416748450

http://teotti.com

[Gregory McIntyre]

+1 in general.

It's been pretty obvious to me, in the past, what the sorts of problems must have been on inherited code. Mostly because I have had to deal with the same clients and pressures that the previous guy had to. i.e. This situation is more than just an engineering one.

I agree with Michael Pearson re. finding explanations for bad code. I find that most of the really bad code is related to decent technicians in tough situations with inadequate management, communication skills or managerial support, resulting in poisoned attitudes, resulting in a feeling of not caring anymore, directly resulting in inadequate tests or poor quality.

Whether or not you believe that the previous guy could have been more professional about the tough situation is probably not helpful.

I think more discussion and training within our professional community about project management (even from the POV of having technical people manage themselves and their own teams such that there is no dedicated manager) would be very valuable.

-Greg