I'm somewhat unique in that I first did a academic career on how to build software and then a, by now, 15 years follow up career actually building software. Back in the day, I wrote an article on what I then called design erosion. And a lot of what I academically pondered there (I wouldn't go as to claim any hard evidence), has sort of been validated in what I've seen in various projects since and backed up by what others have been saying lately.
It's very simple, there are no absolutes in software engineering. The word engineering apart, it is mostly a soft science. That being said, that doesn't mean that you can't be rigorous in how you conduct your business. There are other soft sciences with lots of good practices on how to do things. Economics for example.
Some things I found obvious 15 years ago are that the need to re-visit previously created software design becomes inevitable because whatever assumptions held true when you designed are extremely likely to change over time, thus making whatever was once the perfect design less than optimal. Patching it up erodes the design; these days we call it technical debt. Happens to all software. You can't prevent it.
If you bought into lean software engineering in any way, I highly recommend you check out the awesome work of Don Reinertsen on Lean 2.0: youtube.com/watch?v=L6v6W7jkwok&t=5s
He makes an awesome case for actually a lot of decisions in software engineering being very easy to quantify and has quite a bit to say about things like refactoring as well. The key problem is not that it is hard but that we simply assume it is. Also, there is no need to be perfect with your quantification, because it is pretty easy to out perform our gut feelings by magnitudes (hint, they are mostly wrong and highly inconsistent across teams).
There's a big risk for companies to get stuck patching up existing software for negligible improvements in revenue, or even just protecting already decreasing revenues, when a more wise investment would maybe be trying to figure out what customers really need next and building that. Doing nothing has a risk as well: you'll be left with an out of date completely worthless software stack that is impossible to adapt to new requirements. This kills companies all the time. For reference, just look at the fortune 500 of 20 years ago and check who is still around. Pretty brutal.
So, if you are faced with a software project that is difficult to maintain you have a problem. Step 0 is figuring out the impact of the problem. Is it slowing you down shipping stuff that customers would pay for? If yes, quantify & do the math: that's your lost revenue. Put a ballpark number on it. You have your per head cost and other cost on one side per time unit and you have the potential revenue delta that you are missing out on every month you are not shipping. Now do the math on how much a big refactoring round will slow you down: months not shipping x cost + lost revenue. Finally, do the math on patching up your existing software to get the revenue ASAP. It won't be pretty but if it gets you money in the bank next month, you can't just dismiss it as an option. On the other hand, does it stop there or does it just set you up for being even less competitive in a few months.
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
Thanks for writing such a thorough reply; I think your ideas complement my post nicely.
I agree with so much of what you wrote.
I like the part about software engineering being a soft science. I think Greg Wilson said something similar that I'll paraphrase is "What we do isn't really computer science. It's more like computer strong opinions."
I don't think there's a particular reason we couldn't approach what we do more like an strong engineering discipline. It's just that we work in a young profession full of cowboys--we'll get there eventually.
I'm a huge Reinertsen fan. I've written about his ideas a few times:
Even after writing three long blog posts on his book: The Principles of Product Development Flow, I've only covered the first couple of chapters. (Great book for those who are interested).
I think you're right on the money with your prescription. I'm not sure why more people aren't doing the math to figure this stuff out. Are software developers genetically programmed to avoid any kind of accounting? Just a theory.
Mostly just demographics, Joel Spolsky has some nice numbers on how the demographics are such that the amount of software engineers has been doubling every five years since the sixties. Which, in my age group means I'm out numbered by 24 by younger people, most of which have been active for less than 8 years. Explains a lot about people reinventing wheels.
That and a lot of Academic computer scientists never really figured out that there is more to building software than mathematics.
Another point somebody made recently that stuck with me is that in lots of professions it is common for managers to be practitioners themselves but somehow that is less true in software teams. Kind of odd if you think about it that key decisions in big companies that specialize in making software might be taken by somebody with essentially no direct experience building software; no clue about what is reasonable in terms of quality, technical realization, etc.
A pattern I see a lot in our industry is people with an MBA or some other non technical degree getting the product owner role, which in most companies means they call the shots on a lot of details related to when and what to ship. MBAs don't run armies, don't direct/produce movies, they don't get to head a team of chefs in any decent restaurant. Etc. So, what is so different about making software that it requires oversight by non technical people?
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
Good points. Robert Martin has said similar things about the relationship between the growth in the number of programmers and what that means for our demographics.
I've only ever worked in small companies so I can't speak to the truth of how they tend to staff the product owner role. But what you're saying makes intuitive sense to me. Stereotypical programmer thinking is not well aligned with stereotypical business thinking. Putting an MBA in to middle might help the business types sleep well at night knowing someone like them is in charge.
The thing that might be different is that not a lot of programmers want to be business types because the money is so good in programming and many/most programmers love to code. I've read that is not uncommon for the senior devs to make more money than their bosses. So, in other industries, moving to management is a way to advance your career and make more money. But in programming it means learning about business, getting involved in politics, and watching your extremely valuable programming skills deteriorate, while you supervise people doing the work you actually love. And potentially making less money.
Regarding senior devs, I know a few (myself included) that are more or less self propelled. I tend to think of managers more like customers than leadership these days.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm somewhat unique in that I first did a academic career on how to build software and then a, by now, 15 years follow up career actually building software. Back in the day, I wrote an article on what I then called design erosion. And a lot of what I academically pondered there (I wouldn't go as to claim any hard evidence), has sort of been validated in what I've seen in various projects since and backed up by what others have been saying lately.
It's very simple, there are no absolutes in software engineering. The word engineering apart, it is mostly a soft science. That being said, that doesn't mean that you can't be rigorous in how you conduct your business. There are other soft sciences with lots of good practices on how to do things. Economics for example.
Some things I found obvious 15 years ago are that the need to re-visit previously created software design becomes inevitable because whatever assumptions held true when you designed are extremely likely to change over time, thus making whatever was once the perfect design less than optimal. Patching it up erodes the design; these days we call it technical debt. Happens to all software. You can't prevent it.
If you bought into lean software engineering in any way, I highly recommend you check out the awesome work of Don Reinertsen on Lean 2.0: youtube.com/watch?v=L6v6W7jkwok&t=5s
He makes an awesome case for actually a lot of decisions in software engineering being very easy to quantify and has quite a bit to say about things like refactoring as well. The key problem is not that it is hard but that we simply assume it is. Also, there is no need to be perfect with your quantification, because it is pretty easy to out perform our gut feelings by magnitudes (hint, they are mostly wrong and highly inconsistent across teams).
There's a big risk for companies to get stuck patching up existing software for negligible improvements in revenue, or even just protecting already decreasing revenues, when a more wise investment would maybe be trying to figure out what customers really need next and building that. Doing nothing has a risk as well: you'll be left with an out of date completely worthless software stack that is impossible to adapt to new requirements. This kills companies all the time. For reference, just look at the fortune 500 of 20 years ago and check who is still around. Pretty brutal.
So, if you are faced with a software project that is difficult to maintain you have a problem. Step 0 is figuring out the impact of the problem. Is it slowing you down shipping stuff that customers would pay for? If yes, quantify & do the math: that's your lost revenue. Put a ballpark number on it. You have your per head cost and other cost on one side per time unit and you have the potential revenue delta that you are missing out on every month you are not shipping. Now do the math on how much a big refactoring round will slow you down: months not shipping x cost + lost revenue. Finally, do the math on patching up your existing software to get the revenue ASAP. It won't be pretty but if it gets you money in the bank next month, you can't just dismiss it as an option. On the other hand, does it stop there or does it just set you up for being even less competitive in a few months.
Thanks for writing such a thorough reply; I think your ideas complement my post nicely.
I agree with so much of what you wrote.
I like the part about software engineering being a soft science. I think Greg Wilson said something similar that I'll paraphrase is "What we do isn't really computer science. It's more like computer strong opinions."
I don't think there's a particular reason we couldn't approach what we do more like an strong engineering discipline. It's just that we work in a young profession full of cowboys--we'll get there eventually.
I'm a huge Reinertsen fan. I've written about his ideas a few times:
Even after writing three long blog posts on his book: The Principles of Product Development Flow, I've only covered the first couple of chapters. (Great book for those who are interested).
I think you're right on the money with your prescription. I'm not sure why more people aren't doing the math to figure this stuff out. Are software developers genetically programmed to avoid any kind of accounting? Just a theory.
Cheers.
Mostly just demographics, Joel Spolsky has some nice numbers on how the demographics are such that the amount of software engineers has been doubling every five years since the sixties. Which, in my age group means I'm out numbered by 24 by younger people, most of which have been active for less than 8 years. Explains a lot about people reinventing wheels.
That and a lot of Academic computer scientists never really figured out that there is more to building software than mathematics.
Another point somebody made recently that stuck with me is that in lots of professions it is common for managers to be practitioners themselves but somehow that is less true in software teams. Kind of odd if you think about it that key decisions in big companies that specialize in making software might be taken by somebody with essentially no direct experience building software; no clue about what is reasonable in terms of quality, technical realization, etc.
A pattern I see a lot in our industry is people with an MBA or some other non technical degree getting the product owner role, which in most companies means they call the shots on a lot of details related to when and what to ship. MBAs don't run armies, don't direct/produce movies, they don't get to head a team of chefs in any decent restaurant. Etc. So, what is so different about making software that it requires oversight by non technical people?
Good points. Robert Martin has said similar things about the relationship between the growth in the number of programmers and what that means for our demographics.
I've only ever worked in small companies so I can't speak to the truth of how they tend to staff the product owner role. But what you're saying makes intuitive sense to me. Stereotypical programmer thinking is not well aligned with stereotypical business thinking. Putting an MBA in to middle might help the business types sleep well at night knowing someone like them is in charge.
The thing that might be different is that not a lot of programmers want to be business types because the money is so good in programming and many/most programmers love to code. I've read that is not uncommon for the senior devs to make more money than their bosses. So, in other industries, moving to management is a way to advance your career and make more money. But in programming it means learning about business, getting involved in politics, and watching your extremely valuable programming skills deteriorate, while you supervise people doing the work you actually love. And potentially making less money.
It was indeed uncle Bob that wrote about this blog.cleancoder.com/uncle-bob/2014.... Must have confused the two. Anyway, fun statistics.
Regarding senior devs, I know a few (myself included) that are more or less self propelled. I tend to think of managers more like customers than leadership these days.