Tag Info

Hot answers tagged

91

Actually, this is a very difficult question because there is no absolutely right answer. In our organization we have been putting better processes in place to produce better code. We updated our coding standards to reflect how we, as a group, write code, and we have instituted a very strong test/refactor/design/code loop. We deliver continually or at least ...


87

Is there a point at which the process gets in the way and becomes an end unto itself? Heavy processes are common, unfortunately. Some people - especially management - religiously imagine that processes produce products. So they overdo the processes and forget that it's really a handful of hard-working, smart people who actually create the products. For ...


80

Instead of having two code version with a common base you should design your application in a way to make those premium features plug-able and driven by configuration rather than different code bases. If you are afraid to ship those premium features (disabled by configuration) with the basic version you can still remove that code in a final build/packaging ...


59

A great deal of software work is maintenance. No hiring manager will actually tell you this, of course, but it's certainly the case.


54

One thing I've realized in my career is that there is always time to do it right. Yeah, your manager might be pushing. The client might be pissed. But they don't know how long things take to do. If you (your dev team) don't do it, it's not getting done; you hold all of the leverage. Because you know what caused your manager to be pushing you or your client ...


50

Yes, your perception is accurate. It's an absolute truism that far more time, money and effort is spent on maintaining systems than on creating new systems. So obviously, the time allocation of most programmers is going to reflect that. Part of the reason for that is this a lot of people, when they get to do "new & creative", they do it badly, so that ...


38

One of the benefits for me is the ability to "add" files progressively. Before committing I review each file. Once the file is reviewed, I add it. When I git status or git diff, git shows me only the files that have been modified and have not been added yet. When I have reviewed all the files and added them, then I can commit. So yes, I find the staging ...


38

I strongly recommend not using branches for this purpose. In general, you should consider branches for things that will be (or might be) merged back together again later (or for release branches, where you eventually stop development of one of the branches). In your case, you will never merge your "basic" and "premium" versions together, and they will both ...


34

Split work into separate commits. You've probably many times opened a file to write a single-line fix, but at the same time you spotted that the formatting was wrong, some documentation could be improved, or some other unrelated fix. With other RCSes you'd have to write that down or commit it to memory, finish the fix you came for, commit that, and then ...


23

You should certainly consider splitting the product into modules with interface team(s) bringing those constituent modules together into a product. This in turn would mean splitting the repositories to match the module partitioning and hierarchy. If it appears that you can't do this then the project will probably grind to a merge-induced halt considering ...


22

From the Git SCM Book: Often, when you’ve been working on part of your project, things are in a messy state and you want to switch branches for a bit to work on something else. The problem is, you don’t want to do a commit of half-done work just so you can get back to this point later. The answer to this issue is the git stash command. Stashing ...


21

Companies typically suffer from what I'd like to call the Control-Flexibility dilemma. The less rules, structures and bureaucratic overhead the easier and faster it is to accomplish things (it's also more fun). However, it is equally easy to do "bad" things as "good" things. That means you're only fine when you have skilled employees which make few ...


18

He's mostly referring to the feature branches side of the model. Feature branches were declared an anti-pattern a long time ago when the branches lasted for months and version control systems couldn't merge to save their life. Feature branches that last a week or two have much fewer issues, especially if you're continually merging from develop into the ...


17

Web designers should not usually have to touch the PHP code much, if at all. Usually designers develop the visuals in some graphics package (where needed), usually Photoshop. Build the HTML/CSS for a static version of the content, with alternate content for dynamics also built. Then the programmer tends to take this and make it dynamic. Failing that, ...


17

I fix whichever unit tests aren't working. If they are all passing, then I write a new one.


17

The idea of VERSION CONTROL (misnomer: source control) is to allow you to roll back through history, recover the effect of changes, see changes and why made. This is a range of requirements, some of which need binary thingies, some of which don't. Example: For embedded firmware work, you will normally have a complete toolchain: either a proprietary compiler ...


16

Legacy systems are the successful ones. They survived the initial development process where 50% of projects fail (even after success has been redefined!). They survived a changing business environment. They probably survived about ten proposals by young naive programmers to re-write the whole thing in Java or whatever was trendy at the time. They were lucky ...


16

There is only one solution. Reserve around 10-20% of project/work time for refactoring. If it's difficult to convince the management that it is a justifiable task give them the only real argument: without refactoring the cost of code maintenance will grow exponentially over time. It's good to have a few metrics/articles/research results to back up this ...


15

There is only one valid reason for such style of development: the software developed is absolutely mission-critical and must not, under any circumstances, contain any bugs. Think jet engine fuel injection firmware in passenger planes, or heart pacemaker firmware, or nuclear missile launch system. In all other situations the cost overhead will kill the ...


14

Dropbox For syncing files, it is as easy as working on them within a folder that DropBox knows about. The video on the main page does most of the description, which is why I didn't comment on the features. Simply modify a versioned file and DropBox will upload it automatically, then all other machines with DropBox will automatically download the latest ...


14

With distributed SCMs like git or mercurial (which is what bitbucket uses), branching is still possible but often unnecessary. What you do instead is (basic workflow): Set up a repository in a location that is accessible for all developers (a network share, a server that people can ssh into, a third-party service like github or bitbucket). This will be ...


14

The idea is actually very nice. Contrary to common workflows, you keep the review directly in code, so technically, you don't need anything but text editor to use this workflow. The support in the IDE is nice too, especially the ability to display the list of reviews in the bottom. There are still a few drawbacks: It works fine for very small teams, but ...


14

There might be several issues which are the cause. Potential root causes The classes are too generic/too large. If there is a class Utils, there are chances that it will grow over time. By laziness, everything which doesn't obviously belong to another class would be put in this one. For example, if somebody writes StringToByteArray method, why bothering ...


14

This boils down to what I've started thinking of as "The Eternal Conflict" (between business and engineering). I don't have the solution as it's a problem that never goes away but you can do stuff to help mitigate. Communicate Value What people often don't realize is that as engineers we're just assuming the problem of "successful business" is always a ...


14

Should I commit the test before writing the class even though the test doesn't even compile? Or should I stub out the minimum amount of code that is needed to get the test to compile before committing? Of course not. You should finish both the test and the class. Committing something1 that doesn't even compile makes no sense, and will certainly make ...


13

I use a combination of Git for git repositories and Unison for everything else. I have several unison profiles so I can sync specific things, and one that syncs everything. I also have a bash script that goes through and syncs all the things unison syncs then goes through and updates all my git repositories. Unison is the best thing in my mind when it ...


13

This question really contains two questions, which need to be addressed separately: Why do some teams have a strict development process? The simple answer is because if they don't, mistakes happen. Costly mistakes. This is true for development and it is true for the rest of the IT field as well (sysadmins, DBAs, etc.). This is very hard for a lot of ...


13

Whenever you have time for doing something right, use it - write the best code you can, and improve it steadily. Don't make your job harder by beeing sloppy and introducing technical debt when there is no need to. Emergency calls for fixing a severe bug are no things you can control by yourself, when they occur, you have to react ASAP, that's life. Of ...


12

I know you asked for use cases, but it's easier to list the advantages than to imagine all possible use cases. The advantages of course depend on the engine and language you are comparing, but in general: Keeping rules as data instead of code means you don't have to recompile, so you can test changes quickly, change at run time, etc. Not much of an ...


12

The term that's often used for new projects that aren't dependent on older development is greenfield project. You may occasionally see the term in job listings -- knowing that you get to start from scratch rather than inheriting somebody else's failed endeavor can make a job more appealing. Successful software projects generally spend a lot more time being ...



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