466

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 ...


447

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 ...


336

Ed Yourdon's Death March touches upon a number of these meta type questions. In general, the software industry lacks a lot of the following, which gets in the way of large projects. Standardization and work item breakdown. This has certainly gotten better, but the design constructs still aren't there to break out a big system. In some ways, software can'...


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 ...


242

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 ...


182

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 ...


179

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. ...


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 "...


142

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.


140

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 ...


137

First off: I am a mathematician - a professional one (in that I get paid for doing maths). I am not a programmer. I do do some programming, but very definitely of the Cargo Cult variety (see first comment to https://tex.stackexchange.com/q/451/86 and my response) and nothing of the sort that would normally bring me to this site (indeed, I registered here ...


137

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 ...


128

They call it the Real World™ for a reason. 99% of what you will encounter in the real corporate world will be considered crap, and for good reason that I will explain. The 1% that isn't considered crap will become crap eventually. #1 Write Code, #2 ????, #3 Profit! First off businesses exist to turn a profit, they do not exist to generate mountains of ...


126

The developer knows how their code works and will fall into the habit of testing their code according to this knowledge. The developer will find it difficult to remove themself from the mindset of 'how it works' as opposed to 'how it should work'. Because of this it is better to get someone with a high degree of objectivity to test the program i.e QA or ...


125

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 ...


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 ...


116

If you discover a bug, I can't think of any good reason not to enter it into the bug tracking system, whether you fix it or not. That's what the bug tracking system is for, after all. In some cases it might make more sense to report it to a QA person who has more experience dealing with the system, but in any case the bug should be tracked. It's possible ...


112

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 ...


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 ...


111

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 ...


111

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 ...


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 ...


102

As others (and yourself) have noted, developers should unit test their own code. However, after that, any nontrivial product should also be tested by independent person(s) (QA department and/or the client herself). Developers normally work with the developer mindset of "how to make this work?". A good tester is thinking about "how to break this?" - a very ...


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 ...


102

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. ...


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 ...


101

"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, ...


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