geekhack
geekhack Community => Off Topic => Topic started by: iLLucionist on Mon, 01 May 2017, 06:11:04
-
It used to be that software was just developed properly because you had to ship it on disks. So if there were bugs you'd be making a ****load of disks you had to send again... over mail.
iLLucionist remembers.
Nowadays I almost have an update for something everyday... filezilla... vlc... java... flash... firefox etc.
WHY SO MANY UPDATES W T F. No but really.. why so many though? It's ridonkeylous. And if all of them are security patches the only thing to conclude is that all software is (a) very insecure and (b) the programmers are playing catch up constantly given the many updates.
-
Software is too big and complicated these days.
We've gone from thousands of lines of code to millions.
And hence multiplied the number of bugs in the software logarithmically, as you could keep a few thousand lines of code in your brain, but not millions, so no-one is aware of all the code any more.
We used to be able to just sit down and write a program, run it, and move on to something else.
Now we spend hours setting up the environment, the framework, the debugging tools, the dependencies, compiling, running unit tests, packaging, deploying, and repeating when something almost inevitably goes wrong.
Until fairly recently I was using an exe I created back in, er, the late 1990s I think. A simple command line utility that just did its job. The only reason I had to stop using it was that it did not support files > 4GB in size.
-
Software is too big and complicated these days.
We've gone from thousands of lines of code to millions.
And hence multiplied the number of bugs in the software logarithmically, as you could keep a few thousand lines of code in your brain, but not millions, so no-one is aware of all the code any more.
We used to be able to just sit down and write a program, run it, and move on to something else.
Now we spend hours setting up the environment, the framework, the debugging tools, the dependencies, compiling, running unit tests, packaging, deploying, and repeating when something almost inevitably goes wrong.
Until fairly recently I was using an exe I created back in, er, the late 1990s I think. A simple command line utility that just did its job. The only reason I had to stop using it was that it did not support files > 4GB in size.
Yes, software has gotten quite more complex over time. However, I thought that unit testing, refactoring, design patterns, and best practices (and anti-patterns) would've made up for the increased complexity. Back in the day no unit tests but we could check every line of code, now too much code but fortunately unit testing. Apparently that's not how it works.
-
Software is too big and complicated these days.
We've gone from thousands of lines of code to millions.
And hence multiplied the number of bugs in the software logarithmically, as you could keep a few thousand lines of code in your brain, but not millions, so no-one is aware of all the code any more.
We used to be able to just sit down and write a program, run it, and move on to something else.
Now we spend hours setting up the environment, the framework, the debugging tools, the dependencies, compiling, running unit tests, packaging, deploying, and repeating when something almost inevitably goes wrong.
Until fairly recently I was using an exe I created back in, er, the late 1990s I think. A simple command line utility that just did its job. The only reason I had to stop using it was that it did not support files > 4GB in size.
Yes, software has gotten quite more complex over time. However, I thought that unit testing, refactoring, design patterns, and best practices (and anti-patterns) would've made up for the increased complexity. Back in the day no unit tests but we could check every line of code, now too much code but fortunately unit testing. Apparently that's not how it works.
Unit tests test only what you have written tests for.
All the time I encounter situations that are not tested.
IDEs are getting more and more complicated, and if you're not using an IDE with syntax highlighting, code completion and an integrated debugger then you're already a huge step behind everyone else.
-
Software is too big and complicated these days.
We've gone from thousands of lines of code to millions.
And hence multiplied the number of bugs in the software logarithmically, as you could keep a few thousand lines of code in your brain, but not millions, so no-one is aware of all the code any more.
We used to be able to just sit down and write a program, run it, and move on to something else.
Now we spend hours setting up the environment, the framework, the debugging tools, the dependencies, compiling, running unit tests, packaging, deploying, and repeating when something almost inevitably goes wrong.
Until fairly recently I was using an exe I created back in, er, the late 1990s I think. A simple command line utility that just did its job. The only reason I had to stop using it was that it did not support files > 4GB in size.
Yes, software has gotten quite more complex over time. However, I thought that unit testing, refactoring, design patterns, and best practices (and anti-patterns) would've made up for the increased complexity. Back in the day no unit tests but we could check every line of code, now too much code but fortunately unit testing. Apparently that's not how it works.
Unit tests test only what you have written tests for.
All the time I encounter situations that are not tested.
IDEs are getting more and more complicated, and if you're not using an IDE with syntax highlighting, code completion and an integrated debugger then you're already a huge step behind everyone else.
That's completely true. I once was in a project where all unit tests were written AFTER the spec was implemented. And then they were like "see all unit tests pass" and then they didn't figure out why they had so many bugs in the code. Yeah, really... It was a large government intranet project using typo3 (please never use typo3 framework).
-
Software is too big and complicated these days.
We've gone from thousands of lines of code to millions.
And hence multiplied the number of bugs in the software logarithmically, as you could keep a few thousand lines of code in your brain, but not millions, so no-one is aware of all the code any more.
We used to be able to just sit down and write a program, run it, and move on to something else.
Now we spend hours setting up the environment, the framework, the debugging tools, the dependencies, compiling, running unit tests, packaging, deploying, and repeating when something almost inevitably goes wrong.
Until fairly recently I was using an exe I created back in, er, the late 1990s I think. A simple command line utility that just did its job. The only reason I had to stop using it was that it did not support files > 4GB in size.
Yes, software has gotten quite more complex over time. However, I thought that unit testing, refactoring, design patterns, and best practices (and anti-patterns) would've made up for the increased complexity. Back in the day no unit tests but we could check every line of code, now too much code but fortunately unit testing. Apparently that's not how it works.
Unit tests test only what you have written tests for.
All the time I encounter situations that are not tested.
IDEs are getting more and more complicated, and if you're not using an IDE with syntax highlighting, code completion and an integrated debugger then you're already a huge step behind everyone else.
That's completely true. I once was in a project where all unit tests were written AFTER the spec was implemented. And then they were like "see all unit tests pass" and then they didn't figure out why they had so many bugs in the code. Yeah, really... It was a large government intranet project using typo3 (please never use typo3 framework).
Seen that.
Run the code and see what the output is, then write a test to ensure that it produces that output.
Result = all tests pass - hooray!