464

Foreword This is a daunting task indeed, and there's a lot of ground to cover. So I'm humbly suggesting this as somewhat comprehensive guide for your team, with pointers to appropriate tools and educational material. Remember: These are guidelines, and that as such are meant to adopted, adapted, or dropped based on circumstances. Beware: Dumping all this ...


459

The answer is surprisingly simple: those 'other industries' do have a high failure rate. We're just comparing the wrong things. Writing software is often called 'build', and so we compare it to the manufacturing or construction phases in other industries. But if you look at it, it's not construction at all: it's design. Software designs are written in ...


306

The premise of the question is, frankly, astounding. We suppose that there is a large change to fragile, complex code, and that there is simply not enough time to review it properly. This is the very last code you should be spending less time on reviewing! This question indicates that you have structural problems not only in your code itself, but in your ...


257

There are a few reasons. Nobody reads documentation. Nobody follows the documentation even if they do read it. Nobody updates the documentation even if they do read it and follow it. Writing a list of practices is much less effective than creating a culture. Coding standards are not about what people should do, but are about what they actually do. When ...


245

Even though I use Git on the command line – I have to agree with your colleagues. It is not sensible to squash large changes into a single commit. You are losing history that way, not just making it less visible. The point of source control is to track the history of all changes. When did what change why? To that end, every commit contains pointers to ...


184

To point out some figures: Change of requirements after implementation started; for example when the first Airbus A380 started to be created in the factory I cannot believe that if someone wanted 200 more seats, those would be put there; but in a large software project even after the programmers started development 5 more types of users can be added. ...


178

Good answers so far, but they don't cover all the bases. In my experience, many people fresh out of college have fantastic theoretical knowledge - far better than me or many other seniors with decades building software for a living. BUT, and that's a big BUT, that knowledge isn't grounded in any practical scenario. In the real world, a lot of that theory ...


164

You have to be pragmatic. If the error is unlikely to be triggered in the real world and the cost to fix is high, I doubt many people would consider it a good use of resources to fix. On that basis I'd say leave it but ensure the hack is documented for you or your successor in a few months (see last paragraph). That said, you should use this issue as a "...


143

As far as I'm concerned, your source control repo is part of the basic project setup, so I commit right after I generate my empty project.


142

The premise of the question is a bit flawed. Both the A380 and the Boeing 787 were delivered years late. In the case of the A380 much of the delay was caused by the French and German units of Airbus using different and slightly incompatible versions of CATIA design software. This incompatibly manifested itself as wiring harnesses that didn't quite fit the ...


138

If it is truly a 1 in 10^55 event, there would be no need to code for it. That would imply that if you did the operation 1 million times a second, you'd get one bug every 3 * 10^41 years which is, roughly, 10^31 times the age of the universe. If your application has an error only once in every trillion trillion billion ages of the universe, that's probably ...


135

I am a part-time programming teacher at a local community college. The first course that is taught at this college is Java Programming and Algorithms. This is a course that starts with basic loops and conditions, and ends with inheritance, polymorphism and an introduction to collections. All in one semester, to students who have never written a line of ...


132

Don't put your secret information in your code. Put it into a configuration file which is read by your code at startup. Configuration files shouldn't be put on version control, unless they are the "factory defaults", and then they shouldn't have any private information. See also the question Version control and personal configuration file for how to do this ...


129

An iterative process will achieve this nicely, without detailed specifications. Simply create a sketchy prototype, ask for feedback from the customer, make changes based on the feedback, and repeat this process until the application is completed. Whether the customer is patient enough to do it this way is a different question. Some clients and developers ...


124

In my opinion: yes they are, and yes you should. They give you confidence in the changes you make (everything else is still working). This confidence is what you need to mold the code, otherwise you might be afraid to change things. They make your code better; most simple mistakes are caught early with the unit tests. Catching bugs early and fixing them is ...


115

There's another interpretation. I don't believe it is what Uncle Bob meant, but it is worth considering. Don't capture coding standards in a document. Capture it in code, by having an automated process which verifies the standards are being met. Don't rely on people referencing a document, but at the same time, don't rely on people interpreting the code ...


114

Skyscraper guy here. Not sure if I can answer your question but I can surely shed some light into various items in the thread. Buildings do indeed occur very fast. A major constraint is locale (regulations). But in general it takes 3 to 10 years for a tall building from start to finish. I think comparing a new building with a new software project is not ...


114

Captain Obvious to the Rescue! I'll be Captain Obvious here and say that there's some middle ground to be found. You do want to build for the future and avoid locking yourself into a technological choice or a bad design. But you don't want to spend 3 months designing something that should be simple, or adding extension points for a quick and dirty app that ...


112

Automation. When you are developing, only in the most simple projects will the default "build" button do everything you need it to do; you may need to create WS out of APIs, generate docs, link with external resources, deploy the changes to a server, etc. Some IDEs allow you to customize the build process by adding extra steps or builders, but that only ...


110

I'll take a crack at this from a managerial standpoint, but keep in mind that I'm aware I don't have all of the details. I'll summarize what I see: Mid-level developer, we'll call him "Scott", recommends a rewrite of legacy code into SSIS to improve the performance of important process ProcessA. ProcessA is currently behaving in a functioning state with no ...


110

I like Amon's answer, but I felt one small part needed a lot more emphasis: You can easily simplify history while viewing logs to meet your needs, but others cannot add history while viewing logs to meet their needs. This is why keeping the history as it occurred is preferable. Here's an example from one of our repositories. We use a pull-request model, ...


107

I've seen this done before, both manually by authors and automatically by scripts and triggers integrated with version control systems to add author, check-in comment, and date information to the file. I think both methods are pretty terrible for two primary reasons. First, it adds clutter and noise to the file, especially as these comments age and become ...


104

You should commit as soon as you have a sensible "unit" complete. What is a unit? It depends on what you're doing; if you're creating a Visual Studio project, for example, commit the solution right after its creation, even if it doesn't have anything in it. From there on, keep committing as often as possible, but still commit only completed "units" (e.g. ...


104

"The Mythical Man-Month" came out the year I started college and was, to use the current vernacular, UUUGE! :-) What you need to understand is the difference in how software was developed THEN vs. NOW. Back In The Day (tm) pretty much all coding was done on paper first, was then keypunched onto (you guessed it) punched cards, then was read in, compiled, ...


102

This is a symptom of a wider migration towards distributed version control systems. Some websites which traditionally hosted non distributed VCS (eg Codeplex & SourceForge) were a little slow in adding support for DVCS (eg Git or Mercurial). So, people who wanted to use DVCS for their project were forced to migrate their projects over to the providers ...


101

The very first step would be introduction of a Version Control System (SVN, Git, Mercurial, TFS, etc.). This is must to have for a project that will have re-factoring. Edit: regarding VSC - Every source control package can manage binaries, although with some limitations. Most of the tools in the market has the ability to use a custom difference viewer and ...


100

This is a very common experience Most people I interact with, and I myself as well, feel like this. From what I can tell one reason for this is that you learn more about the domain and the tools you use as you write your code, which leads you to recognize many opportunities for improvement after you've already written your program. The other reason is ...


97

So I don't waste much time on writing super clean code at that point because I never know how long something lasts. Not knowing how long something lasts should never be an excuse for sloppiness - quite the opposite. The cleanest code is IMHO the one which does not come into your way when you have to change something. So my recommendation is: always try to ...


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