Dealing with coworkers when developing, need advice [closed]

Question

I developed our current project architecture and started developing it on my own (reaching something like, revision 40).

We're developing a simple subway routing framework and my design seemed to be done extremely well - several main models, corresponding views, main logic and data structures were modeled "as they should be" and fully separated from rendering, algorithmic part was also implemented apart from the main models and had a minor number of intersection points.

I would call that design scalable, customizable, easy-to-implement, interacting mostly based on the "black box interaction" and, well, very nice.

Now, what was done:

• I started some implementations of the corresponding interfaces, ported some convenient libraries and wrote implementation stubs for some application parts.
• I had the document describing coding style and examples of that coding style usage (my own written code).
• I forced the usage of more or less modern C++ development techniques, including no-delete code (wrapped via smart pointers) and etc.
• I documented the purpose of concrete interface implementations and how they should be used.
• Unit tests (mostly, integration tests, because there wasn't a lot of "actual" code) and a set of mocks for all the core abstractions.

---

I was absent for 12 days.

---

What do we have now (the project was developed by 4 other members of the team):

• 3 different coding styles all over the project (I guess, two of them agreed to use the same style :), same applies to the naming of our abstractions (e.g CommonPathData.h, SubwaySchemeStructures.h), which are basically headers declaring some data structures.
• Absolute lack of documentation for the recently implemented parts.
• What I could recently call a single-purpose-abstraction now handles at least 2 different types of events, has tight coupling with other parts and so on.
• Half of the used interfaces now contain member variables (sic!).
• Raw pointer usage almost everywhere.
• Unit tests disabled, because "(Rev.57) They are unnecessary for this project".
• ... (that's probably not everything).

Commit history shows that my design was interpreted as an overkill and people started combining it with personal bicycles and reimplemented wheels and then had problems integrating code chunks.

Now - the project still does only a small amount of what it has to do, we have severe integration problems, I assume some memory leaks.

---

Is there anything possible to do in this case?

I do realize that all my efforts didn't have any benefit, but the deadline is pretty soon and we have to do something. Did someone have a similar situation?

Basically I thought that a good (well, I did everything that I could) start for the project would probably lead to something nice, however, I understand that I'm wrong.

Answer 1

Refactor mercilessly to get out of the mess!

Take the coding style that accounts for the most part of the usable style and use it for this project.

Worst thing is, that you have to roll back to revision 40, and your programmers had a 12 day training session, that gave them a better understanding of the subject.

If your programmers have that much to learn about clean coding, the twelve days are the least of the delays you will have.

Answer 2

Paraphrasing your question - "I went away for a couple of weeks and disagree with what my team did when I was gone, how do I make them do what I want when I am not here?"

I put it to you that this is not a technical problem, it's a management problem. My take (Please forgive me if I am wrong) is that you dictate the technical solution to an army of minions, who for some reason either cannot or do not agree with or understand your solution.

If 12 Days is all it took to do so much damage to your design, there must be a reason. Is the design fragile? s it over engineered? or did the team just do it out of spite? What are your deadlines and deliveries like? Tight? were they just trying to meet one?

One case I have seen this the technical lead was so far ahead of the game that the average developer (me) could not keep up. The technical lead failed to design commercially viable code, as he was the only one who could maintain it. If a grad developer cannot maintain it, it's too complex for the commercial world. All others cases, it was just plain lack of people management skills on the management side.

The team dynamics are broken. You can (as suggested by others) spend time refactoring the mess and have to do it all again next time you take leave. You may need to up-skill your team members, but I believe you need to fix the team dynamics first, as they appear to have enough skills to get work done, no matter how ugly you believe it is.

Answer 3

Pair.

What you're describing is a lot of doing it right, technically, solo. Yes, you tried to document, tried to impose standards - but you (apparently) failed to communicate.

Well, your team has just communicated to you, rather resoundingly. They said, "Hey, Yippie - you're not communicating!" The most powerful form of communication I know is pairing. Pair. Until they get it, or until they persuade you to do it different.

Answer 4

As Brooks was telling us for the last 30 or so years, conceptual integrity is the most important part of any project. For any nontrivial and complete subsystem there should be exactly one person, responsible for its design and having authority to direct its implementation. Something went wrong with this part in your project. Whatever it was, the only solution is to rollback to the code in repository which existed before that happened. A loss of 12 days is nothing compared with the expenses of maintaining broken design. I would also think of the ways to remove people involved in this srewup from further work on the project, since they proved to be incompetent.

Answer 5

One thing I'd do for starters is to get a good code review tool, using it to mark the bad code and document why it's bad and (conceptually) how it should be done. Now, for what I understood there's a lot of bad things done and so it'd be a lot of work to review; assuming you're the only one that sees something wrong with the code, it may not be feasible to review everything yourself. But you could mark the worst offenses and turn them into entries in your issue tracking system, assigned to the person who wrote the corresponding code.

The best incentive for writing quality code is to know that if you don't, it'll haunt you in the future. Your coworkers don't seem to care about that, so the best medicine is to make them refactor the wrong parts themselves and learn.

Given time, you can revisit other parts of the code that are problematic and again reassign to the original (bad) author. After a while they'll realize the benefits of doing a good job the first time.

I'm assuming that you don't consider a rollback to your original version an option - in other words, despite the bad code your coworkers wrote they added some functionality and the net value of the current version is higher than the original one. I'm also assuming that even if that's not the case, you don't have political capital to do that rollback and make them rewrite the code (as very few people in the planet have such capital). These and many more are the complexities of judging a situation I'm not experiencing myself, but I hope my two cents helped.

Answer 6

One thing I haven't seen mentioned but which has come up recently where I work are the problems of "developer silos" and "buy in".

At the beginning of my current project, I ended up designing a core library basically by myself. (Much like you've done up to rev. 40). Then when I had it done, I presented to the rest of the team and told everyone they could begin using it. What has happened in the subsequent months was that people kept implementing the same stuff that was already in this library in other places. The CTO (who actively codes) points out that there never was a buy-in from the rest of the team on the architecture / design / public interfaces of the library.

Well, we've just gone through a major rewrite of that library which has arguably improved the overall design to better fit what we're currently doing, but again a developer took the library as their only project, worked on it for several weeks and then just presented it. "Voila! Here it is! Isn't it pretty?"

Now that I'm having to use the new version and the same problem is there - I hate the way he did it. And he left out stuff that was necessary because he failed to collaborate with anyone else while he was working on it. So again, I'm starting to implement the same stuff in other places and ways to work for what I need to do.

Long story short - If you want the code quality to increase and to be consistent, I would suggest that you pull the whole team together to establish standards, styles etc. In addition, anytime anyone is going to build a foundational or core piece of your application, I would suggest that the person responsible lead the whole team in designing the classes, etc so that at the end of the day, the whole team has to buy into the overall application architecture. Plus, if they know how other team member's code works, they'll be less likely to implement it again in a way that works for them.

Answer 7

Are you the senior developer (or one of the senior devs) on this team? If so it sounds like you need to hold some training seminars on best practices. You should probably revert much of the work that was done, hold a meeting with your team, and explain the right way to implement the required functionality in a way that maintains the existing design.

Given that you are facing a tight deadline, you may have to ship the code as is, and refactor (rewrite?) after your release.

It also sounds like you need to define and enforce some common code practices. Do you have a code review process in place at your job? If not, sounds like now is the time to implement one. Code reviews are by the way, a great way to teach newer developers best practices.

EDIT:

I ran into a similar situation recently. Management at my company insisted we use contract developers to write much of our application. The code they produced was awful (to put it kindly), but we were forced to use it. As of today, I've rewritten 80% of the code the contractors wrote for us. It was full of bugs and impossible to extend with new features. In a couple more months my team will have rewritten all of it, effectively rendering the money invested in contract development a waste.

Bad code really does cost money, that's something you might want to talk to your managers about, since you'll probably need their help to implement and enforce coding standards.

Answer 8

You made an effort, but the fact is no one is in charge. "But I prefer my coding style", no shit. I'd like to work on my personal projects all day and still get paid.

Hopefully, you can present this to the powers that be and show them what could have been done as oppose to the Wild West Show that went on for two weeks. Seems like you're going to have to get something out the door, but continue to follow-up on the problem of lack of controls and consistency.

Focus on the few that went with your plan and do whatever you can to get them to help fix this mess and get them on your team in future projects. You may just have to reject the rest if they can't get it together.