Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

Any advice would be appreciated, sorry for my bad english.

share|improve this question
Why didn't you sit down with the other 4 programmers before you went on vacation (or even before you started the project), and talk about the design with them? I find that people are much more likely to respect code standards and design infrastructure if you personally involve them in the discussion and explain to them why your design decisions are appropriate. Maybe your design is over-engineered, maybe these guys have a point (though they still should have respected the original design when making changes). I think you should have an immediate meeting, talk about what you're trying to do. –  Marty B Jul 27 '11 at 23:13
Can you improve the title of your question, please? The current title is vague and doesn't really characterize your question. –  Robert Harvey Jul 27 '11 at 23:18
Hi Yippie-Kai-Yay, it's unclear from your question what the practical, solvable problem you're asking us is. Programmers.SE is not a discussion board where you can rant about the day's problems: can you identify the specific problem you need an expert programmer's help with and ask about that? –  user8 Jul 28 '11 at 1:27
@Mark I think that if at least 12 people think that this topic is useful and there is something to discuss, closing it is just weird. –  Yippie-Kai-Yay Jul 28 '11 at 2:01
I think this could be formed into a relevant question (rather than be simply closed) which deals with project management and team work which are important aspects of programming and development. –  Ross Jul 28 '11 at 3:15
show 1 more comment

migrated from stackoverflow.com Jul 27 '11 at 23:06

This question came from our site for professional and enthusiast programmers.

closed as not a real question by Aaronaught, Mark Trapp Jul 28 '11 at 1:25

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

8 Answers

up vote 16 down vote accepted

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.

share|improve this answer
I think this is the only real answer, given the circumstances. –  Robert Harvey Jul 27 '11 at 23:41
When I have solid tests, I don't hesitate to break the everything when bad code is commited. It's the key to keep the project maintainable. –  deadalnix Jul 28 '11 at 0:06
@dead: Umm, what does that even mean? –  Robert Harvey Jul 28 '11 at 2:31
@Robert Well, correctly written unit-tests are actually very nice for refactoring, because you can easily change a lot of things and still be sure that your program is correct. –  Yippie-Kai-Yay Jul 28 '11 at 6:44
@Robert > This means that you shouldn't be reluctant to put some code to the trash when it's not good enough. If you have solid testing, you can then fill up blanks with better quality code and be sure that it will behave the same way with the rest of the program. –  deadalnix Jul 28 '11 at 12:05
add comment


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.

share|improve this answer
I've heard a lot about pairing, but I've never heard of anyone actually doing it and getting benefits. –  Robert Harvey Jul 27 '11 at 23:40
It never works. When you put two horses together, unless they have the same pulling power, one will become a ballast. And in programming we are talking about technical skills, and most importantly, intellectual capabilities. It's very rare to have two people having the same intellectual capabilities that pairing would be successful, and the higher the intelligence the less probability of such event. It's only a conveyor can utilize multiple participants easily, it never happens with intellectual work. All highly successful designs were always the result of one, very rarely two or more brains. –  Gene Bushuyev Jul 27 '11 at 23:45
It works. It works if developers have comparable experience and ability, and it works for both developers if the skills are mismatched. It's amazing how reliably critics of pairing seem never to have tried it. I've done it; I do it. It works. –  Carl Manaster Jul 27 '11 at 23:49
@Carl Manaster > It work with the right pairs. I did it several times successfully, but right now, I'm actually slower and producing worse code with my actual pair than solo. So it's important, if not capital, to pair with the right person. –  deadalnix Jul 28 '11 at 0:04
@Carl Manaster -- I'm always surprised people insist on trying something -- on TV, radio, forums, religious cults, etc. Trying, otherwise known as anecdotal evidence, is not a means of proving anything, it's a logical fallacy. Make a cogent case first, then you can talk about experiments. –  Gene Bushuyev Jul 28 '11 at 0:17
show 1 more comment

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.

share|improve this answer
add comment

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.

share|improve this answer
Nice thoughts, I might have to rethink something. Thank you,. –  Yippie-Kai-Yay Jul 28 '11 at 0:42
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.


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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.