• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Changing Practices

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've just joined a new company and realized that they have many bad coding practices.

- Arbitrary access modifiers a lot of default access field members.
- No standardized directory structure for projects.
- No automated build tools.
- No unit testing used.
- Wrong usage of design patterns.
- No standard code style.

I am not the Chief Architect. Just a senior software developer.

What should I do to change things?
 
Ranch Hand
Posts: 3852
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Nicodemus Chan:
- Wrong usage of design patterns.



Can you give an example of this?
 
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Don't jump off the wagon so early in the game. Maybe your new firm has all these issues and know about it. Maybe they have these issues because of bad management and/or bad developers. Who knows what the reason is but when you first jump into a new environment, you shouldn't bash everything that came before you in an instant notice.
I remember one project I worked on a relatively new guy bashed everything previous programmers and designers did. We were both consultants on a contract, but this guy had nothing but negative things to say about the code, the designs, the system, and he made it known that things were junk. Management didn't like that very much for one. And for another we came to learn that half the system was built 10-15 years before we ever joined. A time when memory management was a key to the way things were developed. That's not much of a concern in a day and age when there are 50 Gig harddrives for 50 bucks. But when this system was developed, 20 MB harddrives weren't always feasible. So certain things done were done for a reason. Yeah over time things should change, but never go into something thinking your all that and condemning everybody and everything that came before you.

I never understood this theory when I was young and I really don't understand it now as I've gotten older. Just because I know the latest and greatest doesn't always mean I know everything. If I jump into a new project, I probably can tell if certain coding standards were used or not. But 1-2 weeks into a new project I sure wouldn't know the reason why certain design patterns were or were not used. Maybe there were timelines, deadlines, memory issues, team issues, who knows what.

As time goes on you may see things that might have been done in a way you think isn't the best solution, but if you are less than a month into a new job at a new company, don't rock the boat so quick. Find out more info before you start throwing around your knowledge and weight.

If you came in as the Sr. Architect to fix things, then maybe you can do this. But if you came in as a Sr. Developer, take some time to learn about the system. There are plenty of people who jump into new projects, act like champs, and then look like fools cause all they do is condmen everybody else without knowing that much more than anybody else.
 
David Aslan
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
e.g Wrong usage of singleton...

public X newInstance() {
x = new X();
return x;
}

public X getInstance() {
if (x == null)
throw new Exception("Error");
return x;
}

True. I understand complaining does nothing but cause friction and reflects more on your character than on what you're complaining about.

I also know that I cannot change things. I can't just come in and tell everyone "I want you to do this, what you're is crap" You need to get buy-in from everyone.

Next, people in management will feel insecure and threatened. People don't like a smart-ass. Coming into their territory.

However, the other extreme for me is to just do nothing and contribute nothing from my experience.

But it's very frustrating to come into an environment that just doesn't have many best practices in place. The coding are done by 20-somethings and by people from India and China.

Knowing how to shoot a gun doesn't make you a soldier, learning how to program doesn't make you a developer either. Just knowing what a class is and how to create methods isn't enough. Software development is a discipline.
 
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Nicodemus Chan:

I am not the Chief Architect. Just a senior software developer.

What should I do to change things?



I would politely and respectfully bringing up the topic. For example ask, "I've noticed there's no standard directory structure for projects, I'm wondering if that's something we might would find helpful; I've seen it used successfully elsewhere. Has anyone looked into this before?" You can start with a peer if you don'tyet want to address the issue with an architect or more senior person.

Remember that successful people don't simply point out problems, they uncover a problem, and bring it to the attention of the appropriate parties along with a solution they are willing to actively participate in. E.g. don't say "you should use an automated build system," but rather, "I think an automated build system might help for the following reasons... I would be happy to investigate options and come back with some concrete proposals for systems that you can use to make an informed decision" or maybe "...I'd be happy to set one up on a small project that we could use as a trial project." Of course, remember that even though you need to do some prep work to have a solution ready, you still must be prepared for them to say "no thanks" despite your efforts.

--Mark
 
Ranch Hand
Posts: 1090
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dunno why but liked a lot what Stephen said. Well Said.
[ May 19, 2007: Message edited by: Anupam Sinha ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic