4

I recently started a new job as a programmer in a small team working on a web-based app. The code base has been built up over 10-15 years, so there is a fair amount of cruft and code that could be modernised. However, it also suggests that the team members don't have a particularly high skill level; there is a lot of data structure juggling that could be reduced to a couple of lines, no real understanding of object-oriented coding, lots of "best practice" violation, and no real application architecture. I feel that everyone (including the boss) would benefit from taking some time out to go on an intermediate-level programming course or two, and the introduction of practices like separating code from HTML content, etc.

My boss is fairly easygoing, but as a newcomer to the team, I do not want to rock the boat (even though looking through the code makes me feel a little seasick!). Does anyone have suggestions on how to approach this situation, and in particular, the skill level of the team?

(In case it needs to be stated, I would never dream of voicing my opinions on the skill levels of my co-workers to them.)

another code monkey
  • 49
  • 3
  • I'd push for things like code reviews and paired programming, and then you would have opportunities to gently critique their code, and hopefully spread some knowledge. – Kai Jun 29 '15 at 19:10
  • 1
    Good luck, it took me ~15 months in a previous job to convince them _to use source control_… – o0'. Jun 29 '15 at 19:19
  • @Lohoris How were they managing versions before source control? For example, making numbered copies of the source tree is still a crude form of source control. Crude as it is it is still loads better than "no source control strategy". – Brandin Jun 29 '15 at 19:27
  • @Brandin they just didn't. And every time they had to merge their huge and complex library, it took them hours doing it by hand. And despite that, it still took me so long to convince them. – o0'. Jun 29 '15 at 19:35

2 Answers2

9

Ask why.

In a best case scenario, the team already knows the stuff is gross, but mitigating circumstances have prevented them from fixing it. The code might've been written by Bob, who was promptly fired. It might be in the plans to fix this stuff tomorrow. It might be in the plans to rewrite the code tomorrow (or another team is doing it already).

In a normal scenario, they have no idea that it could be better. They will respond that they don't really know why it's like that - or "that's how we've always done it". You can then say you've seen this other way, and it worked well. Or that it could be improved by doing it slightly differently. Regardless, you've set the seed of doubt about that code's quality.

In the worst case scenario, they think it's awesome and shut down defensively that you would even think to question their baby.

But no matter the answer, you learn what root problem led to the crufty code - who may be an ally, and who will be a problem. Fixing bad code is pretty easy. Fixing a culture of tolerating bad code is hard, and largely involves understanding the politics involved so you can turn a group of people away from where they will naturally go (with the bad code momentum).

Telastyn
  • 36,240
  • 9
  • 87
  • 127
  • Also, make absolutely certain that no one you're criticizing is somebody in upper management's / ownership's nephew before taking them on. "Bad code" from an entire department is telling of a deeper issue. – Wesley Long Jun 29 '15 at 19:35
  • Be aware that folks are often aware of those best practices( but have practical constraints which make moving to them -- or maintaining them over the life of a real-world project -- difficult. This isn't computer science, it's software engineering, and that means compromises. (Also, not all academic best practices scale well.) Don't assert that you have a better way; ask whether it has been considered and why it isn't as optimal as it seems. – keshlam Jun 29 '15 at 22:29
2

I work in a very similar environment, many non-technical people as well a lot of code outsourcing which has lead to a system that is over 10 years old, not modernized and no-standards. What I've successfully done, is appealed to the CEO by selling him on how standards and best practices will make future development cycles smoother, cleaner and faster. As a result, he has taken note of it, and made an initiative requiring the IT director and outside contract developer to adopt use of Github to maintain a clean codebase from hereon forward, as well as the requirement that all code files be documented, commented, and a bug tracking system be in place. My recommendation to you is to be tactful and professional about how you come across. Most people want to do better but in the midst of project deadlines and excuses like we need it now will attempt to justify dirty coding practices.

Just be persistent yet professional. It will pay off in the long-term. Look at this opportunity as your long-term contribution to the company because if all you ever did was contributed to the company becoming standardized in their coding and documenting practices, that is still a significant contribution and you're helping make a future developer's job that much smoother.

Alex
  • 3,663
  • 17
  • 32