Hot answers tagged

432

Comments alone don't make for better code, and just pushing for "more comments" is likely to give you little more than /* increment i by 1 */ style comments. So ask yourself why you want those comments. "It's best practice" does not count as an argument unless you understand why. Now, the most striking reason for using comments is so that the code is ...


324

Communicate your concerns in the most concise and non-confrontational way possible up the management ladder. Summarize the risks, but do not impose your conclusion on them. Management must always have the choice of what to do, but it is your job to assess and communicate the situation. Use email, so as to leave a paper trail when things go south. Having ...


176

Don't let Scrum become the process which overwhelms everything else My friends and I, who are part of Scrum teams are not fans of it. The reason is that in being the one process which has a dedicated process manager, it usually bends and breaks every other process to it and becomes this overarching process where you do nothing consistently except Scrum ...


136

We have historically seen over and over again that there are two working and two non-working ways of combining the two fundamental constraints on software releases: dates and features. Fixed date, flexible features, aka "release what's ready": you release at a pre-determined date, but you only release what is working. This is a model that is ...


114

I have met lots of devs who had trouble in writing self-documenting code or helpful comments. These kinds of people often lack enough self-discipline or experience to do it right. What never works is, "telling them to add more comments". This will increase neither their self-discipline or experience. IMHO the only thing that might work is to make frequent ...


105

Keep a paper trail (e.g. diary, saved emails, etc). Only include facts and objective observations. Leave all conclusions up to whomever (if anyone) reads what you've written. As a developer, if you're not viewed as an obstacle to the project you're likely to come out fine from the finger-pointing that will no doubt happen. Your manager may not be so ...


104

How do I prevent scrum from turning great developers into average developers? By doing it correctly. All those horror stories I read, being it yours or the other answers, only tell me one thing: those people did not do it correctly. And I get it, it's hard. It's super easy to slap down some rules and have them followed, but that is not Scrum. Scrum is ...


91

I'm going to recommend you take a little time to read 2 books. Death March is the canonical book that describes a pathological project management style that is widespread in software development. Due to schedule compression, feature bloat, or mismanagement, many projects end up in a bad state; it helps to understand that you are not alone and your project ...


77

I'm surprised that everybody thinks this is such a good thing. The authors of Peopleware (which, IMO, is still one of the precious few software project management books actually worth reading) strongly disagree. Almost the entire Part IV of the book is dedicated to this very issue. The software team is an incredibly important functional unit. Teams need to ...


65

Scrum is a process framework defined in the official scrum guide, which says, among other things, the following things about the daily scrum: The Daily Scrum is a 15-minute time-boxed event for the Development Team. The structure of the meeting is set by the Development Team. The Scrum Master ensures that the Development Team has the meeting, but the ...


59

3 simple and cynical strategies to maintain career/sanity. See a train wreck in the making - get off the train: Failing projects are terrible for morale and unless you have ninja upward management skills will have some negative impact on your career. Jump now if you can see any soft landing. If that doesn't work keep your head down: People are going to ...


55

You can quit. Not the most constructive thing to do, but sometimes it's the only option. If you do, don't sit around and moan about how you had to give it up, take that energy and put it straight into something else - 'move on' in other words. You can fork it. There's no reason why you have to work with anyone. Fork, improve the code and let the others ...


54

Everyone altering the application should be doing it in source control, and you should have an automated process for deploying a specific version from source control to your test server. It may require some persuasion to get your non-technical people to use source control, but their really is no alternative to keeping a non-toy system running reliably. If ...


49

Alright, so someone's enthusiastically writing great code that needs to be done, just not in order. With all due emphasis: LET THEM It's causing some complications in your scrum sprints. Does it really matter in the grand scheme of things? If he's accomplishing what he's supposed to, then let him go on and build great things for you. I know several ...


39

You've made it a little unclear exactly what your role is here. The answer depends on how you fit in. If you're leading the project and control the git repository Take back control. If this guy is making commits you don't like without consulting you, remove his direct commit access. He can fork the project and make pull requests to merge his commits. ...


39

There are only two good reasons to report something like this to management: is if you believe that the coder who did this was malicious and attempting to sneak something through, or if you believe that the coder who did this is incompetent, which can be just as harmful as a malicious coder. From the way you describe him, it sounds like you believe he's ...


37

In my 20 years of experience, it is better to have code ownership rotate responsibilities amongst designers or at least have a pair of owners. Single feature ownership has the following issues, several of which you mentioned: it tends to pigeon hole designers and limit their growth opportunities it puts all the eggs in one basket so if someone is hit by a ...


35

What impact will this soon-to-be failed project have on your career at the firm, and beyond? In my experience, merely being associated with successful projects is not an indicator of your own personal excellence. The qualities that you exhibit in the face of adversity and sometimes what looks to be certain failure, often gets noticed by the higher-ups, more ...


35

This is the whole point of code review. Mistake is written. Mistake is found and corrected in code review. Do you want to tattle on your senior team member? This team member according to you has never made a similar mistake before. Unless the code was intentionally written that way (and you can prove it) this is a really dumb idea to go to management ...


35

I'd like to present a counterpoint to most of the answers. As a software developer, I've thrived in Agile teams. Working with a crossfunctional team gave me a better understanding of the features we were building and how they were going to benefit the users. I have used this understanding to explain to management why one bug might need to be fixed now, ...


34

There are two things I think you should consider here: Don't hinder someone's creative flow. If a dev wants to do out-of-hours work, then let them. Don't create work for others. If a dev wants to do out-of-hours work, it sure as hell better not be creating more work for others. Point 2 is likely what the other developers are worried about. Like you ...


34

A couple of things. Don't assume that your seniors don't know what they're doing. They may have very good reasons why they made the decisions that they did; ask them why (in a non-argumentative way). Code that is already written, backed by unit tests, and declared functionally complete by your superiors can be safely ignored. That's what you should do ...


29

Libraries. Frameworks. Version control. If you've got reusable code, the very last thing you want is for different team members to copy the source code into their project. If they do that, chances are that they'll change a bit here and tweak a bit there, and soon you've got dozens of functions or methods that all have the same name but which each work a ...


29

Improve unit tests, functional tests, documentation, tools, etc. There's a plethora of things that can be done in down-time while waiting for the critical path to catch up.


27

I'm surprised no one has mentioned code reviews yet. Do code reviews! When he has a check in of bad quality don't just say "add comments". Constantly ask questions and get him to tell you what his code does and why. Take notes. Then, at the end of the code review give him a copy of the notes and tell him to make your questions fairly obvious. Either by more ...


27

Although I agree with the others on the need to work with the customer and things like that, if you for some reason really think you need to hire new people -- don't hire developers. What you need to do is talk to the developers, and find out what other tasks and burdens you can take off their plate so they can be more productive: If they have a long ...


25

Your questions has the answer in it. Adding man-power to a project that is running late, only makes it worse because the communication overhead increases in a non-linear way. It's already been studied. Read "The Mythical Man-Month".


25

I have actually seen what happens when a "technical manager" gets too heavily involved in the day-to-day mechanics of a project, and it isn't pretty. In our case, the manager in question was not the scrum master but was trying to co-opt some of those decisions; if we hadn't actually had a separate scrum master to play defense then it would have been far more ...


24

I believe the main problem is that as a manager, you have the authority to tell the team what to do. A scrum master does not have this authority outside of enforcing the principles of Scrum. What does this mean? The manager's input will implicitly carry more weight. You might not mean it to, or want it to, but at the end of the day your team members ...


23

In a situation like this, as the lowest rung of the ladder, there is only so much you can do to help the project. Make sure your work is spotless help identify the biggest problem areas Try to provide answers, not just problems. Look like you are trying to fix them. Aside from that, you really do have to look after number 1. Document everything keep all ...


Only top voted, non community-wiki answers of a minimum length are eligible