Tag Info

Hot answers tagged

11

All software design and coding concepts and patterns arise in response to some problem. The pattern or concept is a solution to that problem. Over time, some patterns become "well-known" as preferable solutions because they solve the problem in a way that fulfills certain requirements for consistency, familiarity, performance, maintainability, and so ...


10

Scrum doesn't know nor care anything about management issues. It's a way to organize your work, and to make problems visible so they can be fixed. Scrum can't fix your problem, but it at least can make it visible. Start doing scrum, making any assumptions you want about resource availability. Plan according to that. Follow the scrum practices. When a ...


10

There is no single answer, as this depends entirely on the project. We need to think about two things here. What is your eventual target? How do you expect to get there? End Result Are you writing Mars Orbiter control software? Then you better make damn sure you are writing the most robust code possible, You better be check every exception is handled ...


6

Short answer: No. Longer answer: If your refactorings are truly improvements, then you're engaging in Codependent behaviour - you're supporting your collaborator's bad habits & not giving him/her the opportunity to improve. If your refactorings are trivial, then you're probably wasting your time and/or risking the possibility of falling into an edit ...


5

Managers - These people help your team by removing impediments. You can't write code if you're dealing with sales/marketing/HR/etc. You can't write code if you're dealing with budgets/hiring/facilities. They help resolve differences amongst your team. Instead of having every programmer deal with this crap daily, you designate Bob (who can't code anyways) to ...


5

As pointed out by Bart van Ingen Schenau: The Kanban development method might work well for you. Kanban is a fairly "minimal" method; in particular, it prescribes much less than Scrum. The basic principles are: Visualize the workflow - typically by having (physical or virtual) cards for each task, that move across a board with different phases/steps ...


5

Yes, but I recommend changing how to go about doing it. Rather than refactoring on your own, do a code review. Work on refactoring and cleaning up the code as a group. You clearly know there are better ways to write the code, so share! Maybe your coworker will learn and start writing better code. In the future, maybe you will not need to spend so much time ...


4

There is a very simple and practical approach to this, which works for a wide range of small to medium size projects. Even though it probably won't work well for Mars Explorers. First, work out what you want the system to do and note down each of the individual features. This can be as sophisticated as a whole user story board or as simple as a few bullet ...


2

First, lets start out with "there is no on line provider that allows per brach access control lists as part of its base service." It doesn't exist as such. What does exist, is the ability to do add commit hooks. For example, in git you could put a pre-receive hook on the server. This hook would check to see if the person doing the commit is one of the ...


1

The commonly used term is "feature", although "functionality" seems clear enough as well, especially at requirements gathering stage (we talk about "functional requirements", not "features"). As for the parts, it depends: If you are talking about the parts of the application from the point of view of a developer, those can be "subsystems" (large) ...


1

You have to buy a "Code Signing Certificate". Vendors include Comodo or Godaddy, it costs about $150 to $200. You can make installation packages with it for 1 year. The installation package itself has no expiration date (also look up timestamp option). Some famous freeware products don't have certificates, but they are allowed through because lots of people ...


1

What you have sounds like what is known as an Epic. This is basically a user story that is too large to be implemented, tested and accepted in a single sprint. This should typically be the starting point to go back to the customer and try to derive more details and specifics around what they want. You should be doing this as a regular part of your backlog ...


1

A user story is actually some text of your customer. You should split that story into valuable backlogs. If it's hard for you to write them, because they take too much time to be reasonable valued you have to consider a story split. That means you talk to your stakeholder and recompose the user story in more smaller user stories. The thing is, that scrum is ...


1

Software is weird stuff and the software development process is weirder. Unlike most things in real life, but like most things to do with computers Faster is more reliable This goes against every intuition that you life so far has taught you, highly tuned cars break down more often than standard ones, quickly built houses fall apart more quickly, homework ...


1

I do most things the routine way, the first way that comes to mind. That is quick, and I like to think that I am a decent programmer and I do most things reasonably OK on the first try. Every now and then (I'd like to say twice per day, but twice per week is more realistic), especially when I find something extremely boring to do in the routine way, I think ...



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