I have always had the view that duplication is bad. There are always exceptions, but most of the time I it seems bad to me. Unit tests are one are where I tolerate it more but in production code it's something that I rarely find desirable. Some people duplicate things two or three times and only eliminate the duplication on the third or fourth time. I really can't understand why somebody would blindly follow this rule. I understand the argument that we may not know how to refactor something if there are aren't enough instances of the duplication but I find that it is rarely the case. At least if you don't know how best to refactor something then keep it simple. The rule seems crazy as why would you do something if you know it's bad? Eliminating duplication is usually quick and, in my opinion, usually makes things much easier to read, particularly when you have half as much code to read/understand. As an example, imagine we want to format a number as a currency. We could have the following

x.ToString ("£0.##")

Having it once seems fine, but not really more than once. Surely, as a very simple refactor, something like the following would be better?

Format.AsCurrency(x)

Surely the time saved by the readability would outweigh the code of writing it and it solves the problems of duplication. Deliberately duplicating code doesn't make much sense to me, but maybe I've been working with people who have taken things a bit too far?

Eddy Vluggen wrote:

Ever seen anyone work on a whiteboard, throwing patterns around like they are lego-bricks, explaining to a group of developers the implications of each approach? Half an hour further, the blocks on the whiteboard are work-items, we got to work.

No, I haven't seen it. I've never seen an architect capable of that, although I know a few developers who would be. An architect is ultimately just another developer with a different title. In my current team, I think there are a number of good developers who would have good input on what kind of design/patterns to use. On their own, I don't think any single developer on my team would come up with the best solution. Some of the developers on my team are far better than any architect I have seen.

Richard MacCutchan wrote:

design a system, which the programmers then turn into code

What are senior developers for then? Their knowledge would be wasted if they're just doing what they are told. It's the developers that will be using the architecture so I think it makes sense for all developers to have some input.

I see a lot of jobs for 'architects', but this role doesn't fit in with my beliefs. A lot of modern practices eg. Scrum encourage self organizing teams rather than having a leader. I believe teams can work better without an architect. It seems that an 'architect' or 'lead' would be the next step in my career, but I don't think this is the right title for what I want to do. I think all/most developers should do some architecture design and I think a 'god' role would be too much for one person. What do people think? What should an architect do?

I've been looking at repository pattern implementations (using .Net and EF). Many of them aren't selective. One of the most common methods is GetByID. This gets the whole record. Is this really bad? It will return one record, and in most systems it'll use the primary key. One of the most shocking things I have seen is List GetAll(). This returns ALL records in a table. This is clearly going to become an issue in large systems. Another way some systems work is by using DDD and having aggregates return all related data. This tends to make the code simple, but I have doubts about scalability. Has anybody got experience with a system like this?

The comments have been useful, and pretty much match my thoughts. I was starting to think that maybe my ideas were a little out of date. NOSQL is moving more towards denormalization, which goes against a lot of what we do with relational databases. At the time of writing the post, I hadn't put much thought into joins which will have the biggest problems. I'm looking at some other ways to simplify my architecture without sacrificing best practices and performance.

jschell wrote:

However I do it because there is no guarantee to ordering with '*' and that can matter in a variety of ways such as when using external APIs, dumping data, etc.

I actually use an ORM so it doesn't use * but lists every column (same thing from a coding point of view).

Eddy Vluggen wrote:

Again, you DON'T do a SELECT *. It's not that you save a lot by omitting a DateTime column - but it would prevent that blob-field of 2Gb each that was added last month to be pulled over the network with each and every friggin' request

That wouldn't be an issue in my case. I would never store that kind of stuff in this particular database as it's in Azure and would cost me a a lot of money. Something large would go in a blob or somewhere else.

With SQL people often say you shouldn't do 'SELECT *'. I tend to write highly optimized and selective queries. Do others do selective queries or do you think this is not necessary? The benefit will obviously vary depending on the size and usage of the table. I'm considering simplifying my architecture by doing all of the SELECTing on the web server. There will always be special cases eg. massive tables, but everything is fairly small in this particular application. There are two main benefits I can see from selective queries, less data is transferred and covered indexes can be much smaller. I'm not sure that the amount of data makes much difference when we'll only be getting one screen (eg. 10-50 records) of data at a time. It would be great to hear what others do and think.

Are integration tests worth the trouble? I personally don't like integration tests, or at least not when they're mixed in with unit tests. They are much more costly than unit tests and their benefit seems to be minimal. There was a time when I had to write lots of them for legacy code. They were complicated, took ages to write, forever breaking, very hard to fix and took ages to run. As far as I can see, if you have good unit tests, then the only real benefit is verifying that the IoC container is configured correctly and the config is passed through correctly. All of these things will get picked up by minimal manual or automated UI tests anyway. The time they take to execute is a bit of an issue for. I like to do TDD and like to run all tests after most changes. This isn't practical with Integration tests as they take too long to execute, so I then need to find the test(s) I want to execute and choose those instead of just using a keyboard shortcut. Does anybody know a good way of separating them? Does anybody know a better place for doing these kind of tests ie. no in MSTest or NUnit?

I've been in this situation before. Code re-use is often frustrating. I really dislike reinventing the wheel, but in situations like these it can be hard to tell whether it will be worth re-using the code. One thing to look at when deciding whether to reuse other code is the quality of it. Does it smell? Is it rigid or fragile? I find the answers to those questions are almost certainly a yes. It's very hard to find good quality code. In your situation, maybe it would have gone bad either way? If you write good code and the spec changes then it's going to be difficult.

It sounds like people don't enjoy programming. The reality is that we (or at least I do) spend the majority of our time working. For this reason, I want to enjoy my time at work. Not all jobs are enjoyable, but if you can find an enjoyable one then I don't see why you can't be a programmer for your whole career. I program because I enjoy it, it's challenging and rewarding. I also have a life outside of work though.

List claData = new List();

claData.Add("Test1");
claData.Add("Test2");
claData.Add("etc.");

specs.cla = claData.ToArray();

I've just realised that you've initialised your arrays to 5 elements. This probably isn't a good idea. Whatever is using the array probably won't know it has five elements. Were you expecting something to do

specs.clas[0] = "some text"

? In this case, you can access all elements of the array (and change them) from outside the class.

I saw some nasty code recently. A function took a parameter of a type that was something like Func. You get no clues about the parameters. When (if ever) should we use Lambdas? They seem like a shortcut which will save some time during the initial development, but lose more time later. I think the old fashioned way will almost always be more readable. One place where lambdas tend to be useful is when using LINQ (to SQL or Entity Framework). Is it really that good though? SQL is designed for the job, and performs MUCH better, so why use LINQ to SQL? If we have automated tests then we can fully test that the code is correctly wired up to the SQL.

Nemanja Trifunovic wrote:

At my workplace, checking in requires so much overhead (code reviews, etc) that I am lucky if I check in once a week. That's a bad situation however, and not the best use of source control

This would really bug me. It sounds like there is something wrong with the process.

That's a lot more than me, although if I did 10-20 checkins per day I would probably get in trouble. I'm generally very good. I always comment the checkins, and rarely break the build.

How often should we checkin? I try to checkin as often as possible (although I don't go OTT), and I thought that was considered to be the best practice, but a lot of people seem to disagree. I find it so much easier to work with a small number of files checked out, and the more often I checkin, the less likely it is that I'll get a conflict. The other thing that I think is REALLY bad is when we have periods where we aren't allowed to checkin eg. no checkins while a build is done. Is this normal or is it really as bad as it feels? If people need to have the code stable at a certain point then shouldn't they should either label it or branch it? I see source control as being a very imporant tool that shouldn't ever be taken away from developers. As well as making things difficult (ie. moving onto other things while having other things checked out) I think it would discourage developers from using source control correctly.

RobCroll wrote:

It happens a lot when the KPI is the number of tasks completed. When you see someone doing it all the time and their KPI and wage is twice that of anyone else

That's a very interesting point, I don't know whether our KPI's are based on the number of tasks completed. There certainly are times where people seem to checkin bad code, and are unable to explain why they did it. However, I don't think the management would have a rule like this. They are trying to improve the code quality, although there is always a drive to get work done quickly.

RobCroll wrote:

you got to ask yourself is DRY worth the cost to you personally

Well, I suppose you need to decide what is most important to you. Do we want to be software developers or hackers? We spend a lot of our life working, so I want to make sure that I enjoy my work. However, if you're in a company that has bad KPI's then it's probably best to find a company that doesn't. I think it's probably hard to find a company with a good development team though :( I'm a developer because I enjoy developing software. It's becoming more difficult for me to enjoy it when I know that the code is full of rubbish. I sometimes think that a management/teamleader position would be a better place for me because I could have some influence over the quality without actually having to work with the rubbish. Maybe small companies (with a one or two man team) are the way forward.

Pete O'Hanlon wrote:

It really depends what you're talking about. DRY just means don't repeat yourself. If the code you've taken is from the web, then modifying it to suit your needs is perfectly acceptable. I do agree that it's a PITA when somebody copies and modifies code that they don't understand (we see plenty of that in the forums).

Copying snippets from the web is usually ok. Although I would expect somebody to copy a block of code from the web and paste it in many places. Unless it's a simple, single line of code then it should probably go into something like a function/method. I don't think I've seen cases where people don't understand the code that they copy, but I'm sure it happens.

Code duplication really frustrates me. Is it just me, or do others feel the same? What I'm thinking about is when somebody has clearly copied a chunk of code, and then changed a few lines in the new version. Duplication seems to always cause problems. Some people just don't seem to see the problems though. They will copy code without thinking about it, and give you a puzzled look when you say something about it. It always seems to be somebody else who either has to suffer or spend time refactoring it. In my opinion it's just a 'hack'.