152
The later you test, the more it costs to write tests.
The longer a bug lives, the more expensive it is to fix.
The law of diminishing returns ensures you can test yourself into oblivion trying to ensure there are no bugs.
Buddha taught the wisdom of the middle path. Tests are good. There is such a thing as too much of a good thing. The key is being ...
113
I agree with the rest of the answers but to answer the what is the time difference question directly.
Roy Osherove in his book The Art of Unit Testing, Second Edition page 200 did a case study of implementing similarly sized projects with similar teams (skill wise) for two different clients where one team did testing while the other one did not.
His ...
92
A genuinely terrible programmer can have sub-zero productivity (the bugs they introduce take longer to fix than it would take to just do all of their work for them).
And a genuinely great programmer can do things that poor and average programmers would simply never achieve, regardless of how much time you gave them.
So for these reasons, it's hard to talk ...
89
Once we were halfway the project, the PM stated we had to use third party message queue capabilities instead of threads and had to implement load balancing
This isn't an appropriate thing for a PM to "state" unilaterally. Two reasons:
Design decisions should be made by a technical resource and only in response to NFRs. So politely ask your PM if there is a ...
72
Robert Harvey's answer is good, but I think he left out what may be the biggest reason why programmers are more productive than ever: widespread availability of software libraries.
When I started my career there was no STL, .NET, QT, etc. You had raw C or C++, and that was about it.
Things that used to take days or weeks or work (XML parsing, TCP/IP ...
69
Have you spoken to your development colleagues about this? How do you know they lack education? That's quite a sweeping statement and you'll probably find you're wrong.
I don't think it'd go down too well if a new grad started meddling with processes without understanding why they're like that in the first place. Managers love processes and love tracking ...
65
The argument of the senior architect could mean two things.
It may mean that an average developer in the company produces more lines of code when using static languages than when using dynamic ones. For instance, if fifteen developers work with Java for six months, they will write 100 KLOC, and if the same fifteen developers work with Python for six months, ...
62
For the sake of argument, I disagree with the assertion of Fred Brooks.
There is an improvement in technology which allowed alone an order-of-magnitude improvement in productivity: internet, and more precisely the progressive availability of internet connection in every home in the last two decades.
Being able to find instantly an answer to nearly every ...
58
Do developers in 2014 produce software at a rate less than 10x faster than their counterparts in 1986?
I would imagine that there's been at least an order of magnitude improvement in productivity since then. But not by leveraging one single development, in either technology or in management technique.
Increases in productivity have come about by a ...
52
Since it's not clear from your question, I just want to point out that a gatekeeper workflow is by no means required with git. It's popular with open source projects because of the large number of untrusted contributors, but doesn't make as much sense within an organization. You have the option to give everyone push access if you want.
What people are ...
41
A pretty thorough overview and analysis of research about productivity differences is provided in two articles written by Steve McConnell:
Productivity Variations Among Software Developers and Teams: The Origin of "10x"
Origins of 10X – How Valid is the Underlying Research?
First article (Productivity variations...) states:
...The original study that ...
40
I have worked at a job where check-ins were limited to team leads only (and team leads couldn't check in their own code). This served as our mechanism to enforce code reviews, largely because of a number of incidents where bad commits got into the codebase even around gated check-ins and static analysis.
On one hand, it did it's job. A number of bad commits ...
34
First, be clear on the specific steps that management should take. "Give your programmers more breathing room" is too vague, not actionable, and not measurable.
Second, identify the actual problem. Why are your programmers pulling all-nighters? There's always a root cause or causes, and that root cause does extend beyond "we don't have enough time get ...
33
I tend to solve my most difficult problems:
In front of a whiteboard (sometimes without even drawing anything - just thinking about how to visualize a problem can sometimes lead to a solution)
While explaining them to colleagues
Looking out of the window
While taking a walk
Under the shower
On the toilet
Going away from the monitor is often very helpful ...
31
There is only one study I know of which studied this in a "real-world setting": Realizing quality improvement through test driven development: results and experiences of four industrial teams. It is expensive to do this in a sensible way, since it basically means you need to develop the same software twice (or ideally even more often) with similar teams, and ...
31
What would be stupid is to let yourself get death marched.
What you are describing is that you've lost critical feel. There is no sense of control and no clear way back to it.
The last thing you should do is work hard, keep your head down, and quietly suffer until they finally admit that the project is doomed.
What you should do is think very hard about ...
30
Facts and Fallacies of Software Engineering states (Fact 2, available in amazon preview):
The best programmers are up to 28 times better than the worst programmers, according to "individual differences" research. Given that their pay is never commensurate, they are the biggest bargains in the software field.
(look sources list there for research)
Of ...
29
No. Anyone should be able to commit.
If you have problems with bugs being committed it's not the source control policy which is wrong. It's the devs who fails to make sure that what he/she commit works. So what you have to do is to define clear guidelines on what to commit and when.
Another great thing is called unit tests ;)
There is an alternative ...
28
I try very hard not to write non-answers on this site but I do believe that, in this case, I have to. It's the only right answer. But I'll try to help you out with more than a quip and a "you can't."
In all seriousness, there is no valid measure of developer productivity. I know this is hard for managers to cope with, but it's a fact. Refer them to ...
28
You're never going to be able to solve new problems as fast as you can type. Just accept that. It might work for simple problems you've already done 1000 times.
But there is still value in typing skills. Muscle memory typing allows you to keep your mind in the problem, not on the keyboard. Your mind stays in the zone and the keyboard is just a natural ...
28
I "make tools" when one of these is true:
The task is annoying me
The risk of human error in the task is too big
The "risk" for the 2nd option doesn't have to be huge - the cost of building one small tool is usually small, so if all you save is the risk of running a 10-minute build again once a week, it will usually repay itself very fast.
I try to make ...
26
Yes, it is normal for structured people to be affected by unstructured code/environments. Your colleagues probably are better filtering out all the background noise. As a migraine sufferer I know my ability to filter out my environment greatly drops when a migraine is coming on. People vary.
The same is true for the code, your colleagues have probably ...
26
About productivity and SLOC
The problem with SLOC
The problem with the SLOC metric is that it measures an approximation of the quantity of code written, without taking into account:
the quality of the code (i.e. what if for every 100 SLOC you have to add another 90 SLOC because of bugs, but that you don't know at the moment your code is delivered ?)
the ...
24
Blogs and podcasts are your mentors. Books are your mentors. Videos are your mentors. The Internet has made it possible to have these things in abundance. Pursue them with vigor.
I know this is going to make me sound like an old-timer, but when I was your age I didn't have any mentors. There were no mentors, because they didn't exist. The Internet ...
24
Done well, developing with unit tests can be faster even without considering the benefits of extras bugs being caught.
The fact is, I'm not a good enough coder to simply have my code work as soon as it compiles. When I write/modify code, I have to run the code to make sure it does what I thought it does. At one project, this tended to end up looking like:
...
23
I'd like to add an answer to this question as I've been trudging through some good, bad but mostly ugly Java lately and I have a whole new whopper-load of gross over-generalizations about Java and Java devs vs. JS and JS devs that might actually be based in something vaguely resembling useful truth.
There Are IDEs But It Can Be Helpful to Understand Why ...
22
Your company uses SVN and a bugtracker? Consider yourself lucky! I just graduated and started a new job, my new company version controlled their >100 one-off, ~10 kLOC VB6 and VB.NET apps with ZIP files with dates in the file name. However, my situation is slightly different because they hired me with the expectation that I could help improve the ...
22
Despite there being a lot of answers already, they are somewhat repetitive and I would like to take a different tack. Unit tests are valuable, if and only if, they increase business value. Testing for testing's sake (trivial or tautological tests), or to hit some arbitrary metric (like code coverage), is cargo-cult programming.
Tests are costly, not only in ...
21
The daily scrum's official purpose is as follow:
Communicating to the rest of the team what you did yesterday
Communicating to the rest of the team what you are going to do today
Communicating to the scrum master any impediments or blocked items
Applying this to your case:
Discussion is not a part of the daily scrum, so whether there's anything to discuss ...
Only top voted, non community-wiki answers of a minimum length are eligible
