Tag Info

Hot answers tagged

159

It sounds to me like you are putting the cart before the horse. What is the major problem your team is facing and which technologies would help fix it? For example, if there are lots of bugs, particularly regression-type bugs, then unit testing may be a starting point. If your team is lacking time, perhaps a framework may help (medium to long term). If ...


71

Java? Modern?! You've failed at the first hurdle. If you want to be truly modern and avoid "professional suicide" then you must be writing Rust code. Of course, next week, it'll all change and you'll have to learn something even newer to keep up! Or, you could accept that no amount of buzzword technologies or methodologies or frameworks or any other du ...


37

Many companies are stuck like this; you might even be surprised to find that some of your developer colleagues are self-taught and became developers with no formal background whatsoever. These developers are often better at their jobs, since they will be the ones that are driven to learn new skills and succeed instead of simply doing the job. Unfortunately ...


30

I wouldn't focus on the quantity, but rather on substance. The number of affected files during a group of refactoring operations is as irrelevant as the LOC you write per day. An extreme example is the renaming of methods to follow a convention. It may affect thousands of files, but is barely more important than a refactoring focused on two files which ...


16

I hope you have not presented the issues to your coworkers as you did to us in your post. THAT would be professional suicide. The first issue is that you are trying to teach technologies and methods that even you do not have experience with to a group of programmers that, maybe are a little outdated, but get the job "done". The possibilities of that ...


12

You should start with the book Working Effectively with Legacy Code by Michael Feathers. From the book's introduction, "It's about taking a tangled, opaque, convoluted system and slowly, gradually, piece by piece, step by step, turning it into a simple, nicely structured, well-designed system." He mostly starts with automated testing, so that you can ...


9

Source control. You did not mention it, hopefully because it's already in place, but, in case it's not, start there. Source control has the biggest bang-for-buck, except in rare circunstances pathologically in need of something else. And you can start alone if no one initially buys in.


7

Agree up front how much refactoring is to occur on each ticket. This is done as a team. If that developer wants to do extra stuff, bring it up and decide whether it is OK. Keep things scoped properly. There's nothing worse trying to explain to a boss why the team broke something that wasn't in scope. Also, verify refactoring is actually improving the ...


6

A Direct Answer Other answers make good 'meta-points' about adopting better practices but, just to give you some directly relevant guidance, here's a rough ordering of the best practices I'd suggest your team (or any team) adopt (first): Source control Issue tracking (project and task management) Automated builds1 Automated deployments 1 A very much ...


6

Find a flaw. Fix a flaw. Show the fix. Let's take normalisation* first. And indeed, I'd suggest you take it first, because lack of normalisation is likely to result in actual buggy data that couldn't exist otherwise, whereas the rest are cases where best-practice could likely help but it's harder to say "Bug A was caused by not following policy X". If you ...


6

Where I work, we have a lot of silos of knowledge. Not good. The concern is that it doesn't make sense to have the GUI guy work on Networking stuff, when there is already someone that can (in terms of efficiency) get something done better because they are already familiar with it. Except of course that it leads to this sort of scenario or the ever ...


5

Without being in a position of team lead, the options are somewhat limited. There are different bases of power. The individual in your question won't have legitimate power, as they are not the lead or manager and they don't have the position to drive change. However, depending on their personality, they may be able to develop a position of referent power or ...


5

how many files should one be touching at max? Theoretically speaking you can go on refactoring indefinitely because there is no perfect codebase. One way to get around this that has worked out for me and my team is to identify these areas that need cleaning, make tickets out of them (call it technical debt tickets or anything else along those lines) ...


5

Is this acceptable in agile scrum? Define "acceptable". In some environments, it's fine. In most, it is prohibitively problematic. That problem is that most Business Analysts are horrrrrible. Even when they understand the product well, and even when they can define and scope features, they rarely understand much of the implications of the feature to ...


5

Look around the team that you're a part of. Can you see any evidence that test driven development or database normalization will improve the quality of the software you're writing or make people more productive? Have you tried speaking to one of the development supervisors about it, or the head of development? A really informal chat would be a good start. ...


4

I'm going to go against the grain and say: find a new job after spending some time at this one to build your resume a little. Aim for a year or so. Although many things are "buzzwords," issues like a complete lack of unit testing are intractable for a single developer, and chances are that if the programmers working there have no desire for testing, you'll ...


4

Velocity is defined as "number of units of work completed in a certain interval". To implement a unit of work, you typically have an existing part of software and add some new code and/or change some existing code. When the existing part of software contains a lot of technical debt, and you have to deal with it to implement a change, one would expect to need ...


4

Scrum doesn't really care about the type. A Feature, story, bug, thing, item, use-case... Anything can live on the product backlog. So it doesn't really matter what you call them. The items on the top should have a decent enough level of detail so you can forecast as far as you need and so that the scrum team knows enough to start the work and be ...


4

To some extent, there's nothing you can do if your teams are that specialized. And if you're asking from the viewpoint of a manager, there's nothing you should do, either. This is a problem for the team itself to solve. A point to remember is that scrum tries to optimize the team, not the individual. It's perfectly fine (from a scrum perspective) for an ...


3

Who is the audience for the burndown chart? The second method, where you take credit after the completion of a story, is more in line with the ideas behind Scrum. There are several questions here on Programmers about dealing with incomplete stories (1, 2, 3, 4, and others). A story, not a task, represents something of value to the user. If you take a step ...


3

The word "research" is indeed being overused in agile. The word can be broken down into: learning, or reading documentation, or learning-from-trying. This is just "learning". This is not meant to belittle the time needed for learning. It can take a long time, e.g. weeks to months, but the learning process should be considered and included into the time ...


3

To me this sounds like you and your team mate aren't on the same page when it comes to the level of quality required of the project. I recently had the same problem with a team. What worked for me was determining the ideal design we all agreed on for every part of the project. The repository would use CQS, the MVC controllers would be very thin and ...


2

The important thing is to develop an open, transparent and trusting relationship with the client. The customer needs to understand what your challenges - and cost - are to work in the manner you are being forced to work in. At the same time, you need to understand why is it that the client cannot deliver in a predictable manner. Once there is appreciation ...


2

Well... this happens all the time, and going agile is not going to fix the issue, rather you could get the web service definitions / contracts finalized. At this point you could actually start to build your system with mocking of the client web service using some tool like SOAPUI. Once the customer service is up and running, you can actually test it. Of ...


2

Ken Rubin answered this at a training workshop for us. His advice was to either use a research spike or to use a story task for the training. In your case, you know what product that you are using, and you just need to account for the learning curve. I would recommend a learning task. I remember during the class someone asked if we could just create a story ...


2

One way of looking at velocity is to think of it as "the amount of work that can be completed in a given amount of time". Assuming that fixing technical debt is actual work, it should be counted. You must remember that velocity is just a tool to help you work better. If adding technical debt to you velocity helps you, do it. If it doesn't, don't. The only ...


1

There have been plenty of proposals for improving the programming paradigm. The hottest buzzwords now seem to be agile programming and object-oriented. Or are they? Both have faded substantially compared to what they were just five years ago. You can be fairly confident that whatever methodology put in place is trying to accomplish the same end result: ...


1

My experience; Although there is a 'bug/defect' object in RTC (the collaboration tool used to capture user-stories in my workplace) for the most part my associates tag everything as a general 'task', regardless of whether it can be considered a bug (or group of bugs) or a non-bug task. We do have a Trac-style tool to keep track of the discovery and ...


1

As a consultant, my teams similarly have members with specializations. We need to achieve high quality as quickly as possible in order to best meet our clients needs and our organization's profit margins. It is entirely valid to have team members that are specialized for optimum performance. HOWEVER: This does not mean cross-training should not occur. We ...


1

Most developers are confronted with either creating crappy/less manageable/unscalable/not quite so perfect software in order to meet an arbitrary deadline or they get fired. One reason good programmers are considered good is because they're able to stand up to this because of their reputation, influence, persuasive skills, threatening to leave, etc. Being a ...



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