New answers tagged

-1

The best advice I have heard for software developers is that you want your skills to be T shaped. You should try to have a deep knowledge in at least 1 specific area and a shallower knowledge in a wide area. Only having knowledge in one area means you are limited to that one thing. Having a wide area of skills makes it harder to demonstrate mastery in all ...


0

Unrealistic deadlines/goals are just a fact of life for a dev. Everyone wants it now and wants everything working like they thought it should without having to tell you what exactly they need (including all the one off situations :/ ). I work in development myself and all to often my manager likes to promise crazy deadlines. "Oh ya it will be done by next ...


1

Sometimes this behaviour comes from managers who believe in 'increasing pressure until the pip squeaks'. They worry that you're not working hard enough, and think that setting arbitrary goals will motivate you. I find that the best defence is to point out that under pressure, developers cause more bugs and testers miss problems. It's the managers' job to ...


18

You probably can't. I've been down this road before. Last place I worked, the VP came around and said "the CTO says we have to fix all bugs within 90 days." As we did scrum and I had a backlog and team velocity, I did some quick calculations for my team and the other directors' teams, and said "At the current rate of clearing bugs with the current team that ...


2

I believe you firm need to re-organise the roles and possibly change positions. Here it it why I think so : What’s the role of your manager? Exactly! (S)He should be the the PO and only work with a SCRUM master not a PO and an Adam (aka a semi PO and semi-developer) What happens in you retrospective meetings? Is there any? Are you invited? is Adam invited? (...


3

My take is this: The main argument for outsourcing is that you don't have to take on staff, which is a long-term investment. If you do a one-off software development thing, you probably want to outsource, because those developers wouldn't have anything to do afterwards (most of them, you'll probably need one for bugfixing and updates). The main argument ...


0

With very few exceptions, companies and managers really like people who ask for more responsibility. So don't be shy about asking. You have a First in physics: you don't have to scrape and beg to be taken seriously in your desire to do technical work. You have valuable habits of mind and systemic understanding, and your degree proves it. Frame the ...


0

You have a scrum team. Usually that means you plan what tasks should be done say in the next two weeks, and everyone picks tasks they want to do. Also, everybody should be able to do any task. I suggest that you intentionally deviate from this for a few weeks. Mostly you let people pick their tasks, but you assign the tasks that Adam wants to do to other ...


2

Start by presenting your profile to someone outside the company. You probably have no idea whether you are employable as an entry level developer or not. Your skillset could be anywhere from that of a solid junior developer to a high school kid who knows just for loops and it is difficult to tell the difference without some form of outside feedback. This ...


3

If you can write good code in any language, you can write good code in any language. It is true that your experience with certain technologies will help you get on board with companies who are still using those technologies. Be advised that old technologies are still more common than you may at first have thought; my company's flagship product is coded in ...


0

Just accept the situation as it is and save time? This option is the one that is within your role and scope. Most of the rest is not actually your problem. You've already escalated your concerns and given reasoning. It's out of your hands so don't let it stress you out while you concentrate on fulfilling your own responsibilities.


5

Address the Bus Factor first - give other people tasks that would normally fall within Adam's remit. Get other people in the same technical area up to speed on Adams work. Give Adam sufficient 'make work' tasks that he can't argue with this based on his availability. Once that is in place, assign tasks to Adam in exactly the same way that you assign them to ...


0

What you've described doesn't sound like a "old technologies" problem. Old technologies are great - they're almost all I use and I've made a lot of money with them. Out of date stuff isn't the end of the world as long as you control the deployment environment, which this company seems like it does. The concern from me comes from point 5 - the Copying and ...


2

You've done everything you can. and he fears that Adam might leave the team where he criticizes Adams. Allude to the fact that this lack of clarity is bad for morale and that more team members (including yourself) might leave the team if this issue isn't taken care of.


48

If it’s a core business function — do it yourself, no matter what. There's a wonderful essay written by Joel Spolsky called In Defense of not Invented Here Syndrome. I'll quote some of it here. Indeed during the recent dotcom mania a bunch of quack business writers suggested that the company of the future would be totally virtual — just a trendy couple ...


31

In some comments, the OP has stated that I have no experience and idea about the project development needs after it successfully launched. and this is my first experience and don't know having such website application will need what requirements in future(after it launched successfully) As a first time entrepreneur, you might think that you finish ...


27

From somebody who has done both: Don't outsource to save money. Do it because you need more talent than you can find in your own location. Outsourcing requires remarkable clarity on what you want, and it requires communicating that clear vision, by documents, talks, explanations. If you outsource you need a strong product manager to keep in constant ...


4

I'd say only outsource if you have a very clear definition of what you want, so you can give them a specification, and you can both see and agree when it's done. If you don't have this, you'll spend more time haggling over whether something is a bug (i.e. already paid for) or an enhancement (i.e. more money) than on actual work. Another option is a ...


2

The golden rule: The customer is always right - if the customer pays for it. If your manager comes to you and tells you that the customer is paying for a feature or a change, and tells you to do the work, then you do it. Otherwise you don’t. Find out who in the company can make a decision whether work will be done at all, and for what price. Then when you ...


1

What Kilisi and BigMadAndy said, but it's worth considering another angle. If you're involved in a product that will have a warranty and customer support period, it makes sense to have people in house who are familiar with the development and can suggest solutions. If you're planning a version 2.0, in house development will save you time teaching a [...


46

It's mainly about the stability/ duration of your needs. If you know you will need a full-time person to work for you over the next years, it frequently makes sense to employ one. By employing someone directly your initial cost is higher. It includes onboarding, providing the person resources such as a laptop, etc. But the cost pays out when the person turns ...


7

Outsourcing gives you less control and even less knowledge of the people usually. The big advantage is cost and if you don't have enough ongoing work to keep full time devs productive. So the bigger the company and product line, the more sense it makes to do inhouse. Things like product or information security are factors as well. Handing your product to ...


0

I agree with all the other answers on that you need the contract info to make these decisions and pass the negotiation of features onto whoever is handling those. That needs to go to them. However, I want to add a warning. Be careful just handing off the decision on whether something gets added to the salespeople/management. A feature might be impossible, ...


2

Pass information up, and receive decisions that come down. You should record all the client requests in an issue tracking system, but place them into the backlog (so they aren't worked on). The project manager (you should have one, of some sort, I hope) will review the requests on a regular basis, and decide which ones should be worked on. That PM is the ...


1

Get together with your sales people/whoever manages the business side of the contracts for which you do the development. You have information they need, and they have information you need. You need to know what you should do for the clients. The sales folks need to know what you could do for the clients, and how hard (read: expensive in salary hours) it ...


12

We don't have access to business information (what kind of deal a specific user has with the company that employs us). This is the key thing. Unless you know the contractual details of a customer you can't make a decision as to how to reposed to a customers request. The obvious thing is boot the request further up your managerial tree until it hits ...


11

With no mention on my resume of not having passed the jury yet. I rarely got asked about it and never brought it up myself. So you put the degree on your resume without actually mentioning the trifling detail that you hadn't actually finished it? Well, I can't possibly see how that would come back to bite you in ass.. Now they're asking for a bunch of ...


2

Assume you add a feature and rely on an existing function in the code, that was working quite fine until now. Your code breaks, but it breaks because the function does not do what it should do. It worked for the existing code, but it does not handle edge cases, that are needed for your code. Someone else wrote a unit test for it that does not test the edge ...


0

If someone drives your car into a ditch, are they really the right person to trust to get it out? Lets suppose for a minute that management is right, and for some reason the developers on this one team are much more apt to create bugs when they change code than the rest of the company's developers. Its not the nature of the tasks they work on (the most ...


-1

One point not made elsewhere is that non-trivial bugs are not simply attributable to one simple programming mistake. Typical example: you invoke a method (in "someone else's code", if you have such a concept) passing a zero-length array, and the code breaks because it wasn't expecting a zero-length array. Whose bug is it? Don't even waste time arguing about ...


1

Stages of the software development life cyle as defined by the Agile Model: Analysis Design Implementation Testing Deployment Maintenance Your problem appears to lie between stage 3 and 6. To reduce bugs in production you have to ensure the following: Each developer writes unit tests for each class (code) they create / change (see Test Driven Development ...


-1

What may be some possible regression issues of this policy? If your team members are occupied fixing bugs, how would you as the coordinator able to contribute anything? Bugs should all goto the team leader (or coordinator in your case), it's your job to address them before asking for developers' help. Development is hard, developers are busy, so they may ...


-1

The answer of @jeffrey is good, but I disagree in one thing: this is not the worst what can happen. The worst thing what can happen is that developers will tip-toe around difficult code parts even more than before. They will artificially introduce boundaries just to protect them from the start from responsibility. The result will be that function complexity ...


-1

One thing I have not seen mentioned here is that this strategy calcifies the code. Presumably the code of the different developers must interact. Say that one developer introduces a bug that is best fixed by refactoring another person's code. What happens then? The other developer will oppose changing his code as then the bug becomes his problem. Over time,...


6

Another big drawback I see is about code ownership. In a scrum team, it's important that the entire team feels responsible for the entire product. This policy also means that if developer A caused a bug, developer B won't fix it, thus making sure he won't feel responsible for that code. This is likely to lead to an increased bus factor and friction within ...


-1

Fundamentally such proclamations remove a degree of freedom from your ostensibly agile team. When problems occur you are simply constraining the pool of people who can fix them for reasons other than optimality. One argument from optimality would be that the person who wrote the code is best placed to fix it, which flexi notes but says only applies shortly ...


4

Your problem is that your developers produce code that is later found to be buggy, and that to a degree that your manager feels is too much. There's always a possibility that you have a team manager who is just incompetent - in that case, that team member should not be the one fixing the bugs. That team member should be removed. But say that is excluded as ...


72

Let's back up a second. I’m a software coordinator who leads a Scrum team What's that? Because I can read the Scrum Guide to learn what a Scrum team is, and it tells me: The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to ...


19

Your manager is misguided and taking you along on a misguided journey. You break it-you fix it mentality places weight on assigning blame and dishing out punishment. What you’ll get will be “It’s not my code, it’s your darn requirements.”, or “You gave my method garbage data, garbage in-garbage out” or “The database is slow, my code is just fine”... you get ...


6

I'm going to take things a step further than a lot of the other answers here: You are definitely the bad guy in this story. Let me take a few nuggets from your question: Many people also get frustrated with IT and instead contact us for help. He ignores those people Let me rephrase that for you. He doesn't work in IT. He presumably wasn't hired to ...


13

This isn't an issue of individual accountability lacking. This is an issue of the logistics framework allowing a large amount of bugs to leave your area. Or in short: What's Your Test Plan? I've been dev-ringleader over three projects the last few years. The first had unit tests and a small number of integration tests built in to it. I could make a few ...


5

If a dev deploys something and it comes back in the same week, then the original dev is best placed to fix it. - I have found this works well. However, if it has been more than a few months you can't really do this. The original dev will be focusing on another project, and breaking that focus isn't good. I worked for a company that tried 'you broke it, you ...


41

Assigning blame in this manner is very likely to cause loss of morale and the emergence of extremely dysfunctional behaviours such as: developers refusing to work on code written by others developers refusing to work on old code developers refusing to work on high-risk code or features inflated estimates; reduced cooperation; .... The rise of a blame ...


3

The biggest issue I can see is that you probably won't reduce the bug count by any significance, but you will increase the pressure and stress on individual developers. What you need to look at is why and how these bugs are occurring and getting through to production. First up, communication. Do your developers talk to each other as they work on tasks? Do ...


0

The main drawback would be developers actively trying to hide bugs (theirs and their colleagues'). The end result would be more obscure bugs, very well hidden. This looks like a scenario straight out of the original freakonomics book. Go read it :-). This wouldn't happen intentionally. It simply would happen that developers who code in a way where their ...


75

What would be the downsides of having a “you break it, you fix it” policy in the dev team with the goal of reducing bugs? The downside is that you may spend a lot of time trying to chase down who introduced the bug, which in turn could lead to a "blame culture". There is a tactical way to address this situation right now and there is a longer term strategy ...


194

In my experience bugs are a consequence of (in no particular order): Poorly defined or constantly changing requirements. Too much work for the amount of time provided, which leads to rushing, which leads to mistakes, and insufficient time to test and fix defects before release. Lack of peer code reviews (may be related to point 2). Insufficient QA ...


3

Some great advice I got early in my career: Every day you go to work, ask what you can do today to most move the company forwards. This is what your coworker is doing. It's smart, and is rightfully being rewarded. Yes they are behaving arrogantly at times. But give them a break. That's pretty common for young people who do well quickly and get external ...


0

I am a developer and I also don't like maintenance, indeed it can be compared to janitorial work. The best thing about my job is to be creative and to build things from scratch. But when you do maintenance: You lose a lot of time understanding someone else's code, which is often messy You don't use your creativity, but you just modify something that already ...


Top 50 recent answers are included