41–50 of 212 posts
What annoys me most about these metrics is that some days zero lines are written. Anything up to a month without results to show. Where, then, does all this time go? Sometimes it's reading existing code. Sometimes it's learning about a new algorithm by reading blogs and papers. Sometimes it's developing test programs to iron out a bug or test out some new code. There used to be one chap in the office that got all the…
Earlier quoted context omitted.
This is the engineering point of view, but in a business productivity is judged from a business point of view. The goal of software development is to deliver chargeable value to customers. When you refactor code you do not deliver value to customers and since you have spent time and resources to do that your overall productivity from a business point of view has in fact dropped.
When you refactor code you do not deliver value to customers.. You do though, by reducing the future cost of delivering features. That has tremendous value. Find a company that sees good engineering as a long term investment rather than a short term way of extracting money from customers and you'll enjoy software development a lot more.
Refactoring is an internal activity. It's part of the cost of development.
10 lines per developer day - this is so outdated it should be disregarded entirely. Not much is gained from writing articles around this "10 lines a day" assertion unless you're writing something about computing history. Maybe this was true when people were writing operating systems in assembly language - which is the time and context in which The Mythical Man Month was written. Lines of code per day really is a pret…
People misunderstand it. It means writing code, documentation, testing, bug fixing etc. I'm not sure it is that far off over several years. If you look at Google, and say there are 52 * 5 days * 10 lines of code, 2600 lines of code per developer. Extrapolate that to 20 years times how many developers and list on code that is currently used, would it be that far out? People over-estimate the sustainability of short te…
Earlier quoted context omitted.
When you refactor code you do not deliver value to customers.. You do though, by reducing the future cost of delivering features. That has tremendous value. Find a company that sees good engineering as a long term investment rather than a short term way of extracting money from customers and you'll enjoy software development a lot more.
Will you be able to sell more software or increase the price of your software because you refactored some code? No, your customers don't care two hoots about that. Refactoring is an internal activity. It's part of the cost of development.
Yes I will, because the cost of development will be lower. That makes my customers happy so they give me more work. I'll also have fewer defects which improves my reputation which means I can charge more.
No, your customers don't care two hoots about that.
I mostly write software for SaaS companies. Their customers (the end users of the software) don't care about it much besides seeing fewer problems and getting to use better software, but my customers (the people who own the software) really do.
Earlier quoted context omitted.
Will you be able to sell more software or increase the price of your software because you refactored some code? No, your customers don't care two hoots about that. Refactoring is an internal activity. It's part of the cost of development.
Will you be able to sell more software or increase the price of your software because you refactored some code? Yes I will, because the cost of development will be lower. That makes my customers happy so they give me more work. I'll also have fewer defects which improves my reputation which means I can charge more. No, your customers don't care two hoots about that. I mostly write software for SaaS companies. Their c…
Edit:
I'm not arguing that refactoring isn't necessary or important. It is. But it should be kept to a minimum because it really is a pure cost and does not deliver anything of value to end users.
Your customers are the engineering teams of software business. They sometimes need to refactor their code. But their business would prefer they didn't because that's money spent on something invisible to end users (the end customers).
But one of the things that hasn't changed is that we haven't really come up with any better metrics than time spent and nr. of things changed per time unit. There are a lot of people complaining these things are not representative (for the last five decades) but not a whole lot of people coming up with better productivity metrics and even fewer that did the leg work of actually validating their work in something that might pass scientific scrutiny (which is hard). If you do work in this space, you'll find yourself citing articles that are decades old.
These days, I tend to look at the activity statistics on github projects when joining a new project. It tells me in a glance of an eye who are the movers and shakers on a project in terms of lines of code added/removed and amount of commits and the time distribution of those commits. It's not perfect and doesn't tell you the complete story but it it's rarely completely wrong. Usually it's quite easy to spot patterns like Weekends, Christmas, vacations, and that people tend to get back energized from a good break (a little spike in productivity).
Also these numbers confirm the notion of a 10x programmer: a handful of people tends to be responsible for the vast majority of commits and line changes. Not all software engineers are created equally. Diffstats on pull requests tell me a lot as well; though of course these numbers are inflated by e.g. refactorings (more so on languages that have proper tools for this). But refactoring is a good thing and combined with code reviews tell you a lot about the quality of engineering.
10 lines per developer day - this is so outdated it should be disregarded entirely. Not much is gained from writing articles around this "10 lines a day" assertion unless you're writing something about computing history. Maybe this was true when people were writing operating systems in assembly language - which is the time and context in which The Mythical Man Month was written. Lines of code per day really is a pret…
People misunderstand it. It means writing code, documentation, testing, bug fixing etc. I'm not sure it is that far off over several years. If you look at Google, and say there are 52 * 5 days * 10 lines of code, 2600 lines of code per developer. Extrapolate that to 20 years times how many developers and list on code that is currently used, would it be that far out? People over-estimate the sustainability of short te…
Are you sure about that?
I don't think so.
I have not read it for years, but my vague recollection of The Mythical Man Month is that 10 lines a day as a full time professional programmer is a reasonable expectation if you are writing IBM mainframe operating systems in assembly language in the 1970s.
It not meant to be saying that hey a programmer is busy with lots of other things like testing documentation etc.
Brooks actually meant it, and it was true, at the time, with 1970s hardware, with 1970s development tools, with 1970s collaboration, 1970s compilers/assemblers, 1970s source control, with 1970s level of understanding of computers and software, with 1970s waterfall style project management. And, critically, writing your 10 lines as part of a (relatively speaking) gigantic project for the time. Back then projects did not come much bigger than writing an operating system.
Can you imagine trying to get your bit written of some gigantic project where probably no-one has any idea what the fuck is going on, where the source code is, what version is what, who is working on what and how its all meant to tie together. The miracle is that they could get any operating system at all written. Many, many operating system projects failed entirely in the 1970's and 1980's.
I'm happy to be proven wrong, cause as I say I haven't read that book for a long long time.
10 lines per developer day - this is so outdated it should be disregarded entirely. Not much is gained from writing articles around this "10 lines a day" assertion unless you're writing something about computing history. Maybe this was true when people were writing operating systems in assembly language - which is the time and context in which The Mythical Man Month was written. Lines of code per day really is a pret…
People misunderstand it. It means writing code, documentation, testing, bug fixing etc. I'm not sure it is that far off over several years. If you look at Google, and say there are 52 * 5 days * 10 lines of code, 2600 lines of code per developer. Extrapolate that to 20 years times how many developers and list on code that is currently used, would it be that far out? People over-estimate the sustainability of short te…
Here's an example: https://github.com/sumatrapdfreader/sumatrapdf is code written by 2 people (me and another guy).
It's written, documented, tested and bug fixed.
It's 110k lines of code. And it's tight. Good luck removing 10k lines of code and not loosing any functionality.
Assuming 10 lines per day and round-the-clock 365 days of working, that's 30 man-years of work. 15 years for 2 people.
I didn't spend 15 years writing it. It's a part-time effort over 10 years.
The 10 lines per day is off by at least an order of magnitued.
And I don't claim to be spectacularly productive. Jonathan Blow wrote 90k lines of code for Braid in 1 or 2 years.
Earlier quoted context omitted.
Will you be able to sell more software or increase the price of your software because you refactored some code? Yes I will, because the cost of development will be lower. That makes my customers happy so they give me more work. I'll also have fewer defects which improves my reputation which means I can charge more. No, your customers don't care two hoots about that. I mostly write software for SaaS companies. Their c…
If you're arguing that you might get paid as a contractor to refactor some code therefore refactoring is a productive activity for a business point of view then you have completely missed the point. Edit: I'm not arguing that refactoring isn't necessary or important. It is. But it should be kept to a minimum because it really is a pure cost and does not deliver anything of value to end users. Your customers are the e…
Specifically in my own case, the company I work for writes software for (mostly) software product companies. When we plan what to do in a sprint 'refactoring' is part of that. We literally charge for the time we spend doing it. How long we spend refactoring is agreed by the customer's project / product manager. They understand why it's necessary and important, and they want us to do it.