I have degrees in math/CS and psychology; took several Psy stat courses. The courses were good, but more focused on concepts and did not require a lot of hard calculation beyond relatively simple algebra. Nonetheless, I learned a lot about stats in psych that was often more practical that the stuff I learned in my math classes.
Yeah, I'd have to say I'm with you on this one. I once failed an interview because the interviewer wanted me to say that java Strings are immutable, and it's been maybe 10 years since I consciously thought about it. Hell, the times it really made sense to use a StringBuffer or a StringBuilder instead of using simple String concatenation have been few and far between.
The types of performance issues I see are attributable to architecture and design, such as 1) code so complex it retrieves the same large dataset 39 times during initialization of the app; 2) Deep data fetches to populate 25 backing views for a list of items being displayed, because someone decided it was more 'performant' to populate large data structures and UI objects for when that when the user selected something from the list, the associated detail view would pop up immediately. Never mind how long it took the list to display. 3) designing a data model to optimize the production of XML transport data, rather than modeling entities of the business domain and treating serialization of that data as a byproduct, rather than the product itself.
Stupid, stupid things kids worry about. And if you don't think I know anything about writing Java code, you can download and run this.
I think back to all those high school pep rallies and see them now as a form of brainwashing. Why were we cheering for the jocks and pretty prom princesses? What have they done for the rest of us?
That's DataSAAB Interpretive Language / DataSAAB Assember Language. Back in the days of minicomputers with magnetic core, punchcards, paper tape readers, and hard disk drives the size of washing machines.
It's not only optimizations that an immature software process will get bogged down in (optimization increases complexity, for sure); but the tendency to be enamoured by the current fad development stack (as noted in the article) because it will somehow magically make all the cruft built into their current stack go away. It's like calling 'do-overs' instead of going back and working in the small to make incremental simplifications of process, configuration, data models, and api. That's just too unsexy for most young developers, but we mature guys know that new tools != better outcome.
Mr. McGuire: I want to say one word to you. Just one word. Benjamin: Yes, sir. Mr. McGuire: Are you listening? Benjamin: Yes, I am. Mr. McGuire: Plumbing. Benjamin: Just how do you mean that, sir? Mr. McGuire: It can never be outsourced.
Oh, come on. Do you think the complexity of these robots won't lead to breakdowns and glitches? And how cheap is it to replace a robot vs. a mule? It would be cheaper to add bionics to the mule.
we mixed a little dirt in a cup of cold water and called it instant. If you wanted creamer, you added drop or two of Liquid Paper. Tasted like shit, but the extra chemicals and minerals kept you going.
To get to the first 0 pointer in the list? Perhaps, but what if the list is very large? Wouldn't a wrapping class that maintains the list's last node work faster?
I've worked with teams a large percentage of (supposedly) hotshot programmers, and on teams with a similar percentage of mediocre talent. In my experience, it is the team with the so-so developers that deliver the more maintainable code. Why? I think it's because they know their limitations and are not afraid to "talk out the process" of writing code. They ask for feedback and opinion.
What that leads to is a collaborative development process, where everyone has some idea of what the other is doing. And in these environments, for some reason, people take ownership and responsibility for their code, end-to-end.
Contrast that with the hotshot teams: they know too much to ask for help, resent questioning of their implementation, mess around in other peoples domain "because they know better", and engage in heated arguments over trivial or religious matters. And in the final analysis, the lack of cooperation leads to disfunctional interfaces between components, idiosyncratic code, and incomplete functionality or low-quality performance.
Whereas the so-so teams learn to collaborate to get things done, the hotshot teams rely on heroics: they take on too much, show exaggerated progress by declaring their code complete even though it fails edge cases, and then spend outrageous overtime fixing 'bugs' (or worse, they're too important to work on bugs, they do features, so the lesser mortals on the team get to clean up after them). Because bug fixing doesn't get scheduled up front, the schedule slides and more work hours are demanded to catch up (with decreasing effect).
To my mind, the MAIN criteria for arriving at a maintainable codebase is OWNERSHIP, OPENNESS, and COLLABORATION. A collaborative team can do more in 40 hours than a heroic team can do in 60. They just don't look so impressive.
I saw a demo of OV and thought it was going to big boost in productivity for getting an app up and running. Problem was, the programming language was based on spreadsheet commands, and there were no arrays(!). I worked in a 4GL back in those days called DataFlex (still around, btw) and it didn't have support for arrays, either.
Why would you design a programming language without array support?
I seem to recall a multitasking PC OS called WendesDOS, developed by a pair of brothers named Wendes back in the mid-80s. Microsoft bought them out and employed them, if I'm not mistaken. They use to have (small) ads in Infoworld, but I can't locate any info on it now.
Slashdot Mirror
I have degrees in math/CS and psychology; took several Psy stat courses. The courses were good, but more focused on concepts and did not require a lot of hard calculation beyond relatively simple algebra. Nonetheless, I learned a lot about stats in psych that was often more practical that the stuff I learned in my math classes.
Yeah, I'd have to say I'm with you on this one. I once failed an interview because the interviewer wanted me to say that java Strings are immutable, and it's been maybe 10 years since I consciously thought about it. Hell, the times it really made sense to use a StringBuffer or a StringBuilder instead of using simple String concatenation have been few and far between.
The types of performance issues I see are attributable to architecture and design, such as 1) code so complex it retrieves the same large dataset 39 times during initialization of the app; 2) Deep data fetches to populate 25 backing views for a list of items being displayed, because someone decided it was more 'performant' to populate large data structures and UI objects for when that when the user selected something from the list, the associated detail view would pop up immediately. Never mind how long it took the list to display. 3) designing a data model to optimize the production of XML transport data, rather than modeling entities of the business domain and treating serialization of that data as a byproduct, rather than the product itself.
Stupid, stupid things kids worry about. And if you don't think I know anything about writing Java code, you can download and run this.
Too true, too true.
I think back to all those high school pep rallies and see them now as a form of brainwashing. Why were we cheering for the jocks and pretty prom princesses? What have they done for the rest of us?
You are humor impaired, Mr. Booger.
Everyone knows that newts are smarter.
That's DataSAAB Interpretive Language / DataSAAB Assember Language. Back in the days of minicomputers with magnetic core, punchcards, paper tape readers, and hard disk drives the size of washing machines.
Sounds like you and I were on the same project! But then, every Boeing software project sounds like what you described.
As stated in the animation: 'pecisely twisted'. Makes me wonder.
It's not only optimizations that an immature software process will get bogged down in (optimization increases complexity, for sure); but the tendency to be enamoured by the current fad development stack (as noted in the article) because it will somehow magically make all the cruft built into their current stack go away. It's like calling 'do-overs' instead of going back and working in the small to make incremental simplifications of process, configuration, data models, and api. That's just too unsexy for most young developers, but we mature guys know that new tools != better outcome.
Two six-digit accounts talking about the good ol' days of Slashdot. Precious!
I thought they said you was dead...
Mr. McGuire: I want to say one word to you. Just one word.
Benjamin: Yes, sir.
Mr. McGuire: Are you listening?
Benjamin: Yes, I am.
Mr. McGuire: Plumbing.
Benjamin: Just how do you mean that, sir?
Mr. McGuire: It can never be outsourced.
if only because of the giant wooden Energizer Bunny on the packaging.
Oh, come on. Do you think the complexity of these robots won't lead to breakdowns and glitches? And how cheap is it to replace a robot vs. a mule? It would be cheaper to add bionics to the mule.
Great! So you're arguing for a 100% estate tax, then? I would have settled for 90%.
we mixed a little dirt in a cup of cold water and called it instant. If you wanted creamer, you added drop or two of Liquid Paper. Tasted like shit, but the extra chemicals and minerals kept you going.
To get to the first 0 pointer in the list? Perhaps, but what if the list is very large? Wouldn't a wrapping class that maintains the list's last node work faster?
What do 's' and 'ss' stand for?
I've worked with teams a large percentage of (supposedly) hotshot programmers, and on teams with a similar percentage of mediocre talent. In my experience, it is the team with the so-so developers that deliver the more maintainable code. Why? I think it's because they know their limitations and are not afraid to "talk out the process" of writing code. They ask for feedback and opinion.
What that leads to is a collaborative development process, where everyone has some idea of what the other is doing. And in these environments, for some reason, people take ownership and responsibility for their code, end-to-end.
Contrast that with the hotshot teams: they know too much to ask for help, resent questioning of their implementation, mess around in other peoples domain "because they know better", and engage in heated arguments over trivial or religious matters. And in the final analysis, the lack of cooperation leads to disfunctional interfaces between components, idiosyncratic code, and incomplete functionality or low-quality performance.
Whereas the so-so teams learn to collaborate to get things done, the hotshot teams rely on heroics: they take on too much, show exaggerated progress by declaring their code complete even though it fails edge cases, and then spend outrageous overtime fixing 'bugs' (or worse, they're too important to work on bugs, they do features, so the lesser mortals on the team get to clean up after them). Because bug fixing doesn't get scheduled up front, the schedule slides and more work hours are demanded to catch up (with decreasing effect).
To my mind, the MAIN criteria for arriving at a maintainable codebase is OWNERSHIP, OPENNESS, and COLLABORATION. A collaborative team can do more in 40 hours than a heroic team can do in 60. They just don't look so impressive.
Could it be that we often repeat repeat ourselves in midsentence?
These are the people commonly referred to as Engineers.
Found it. It was called Wendin-DOS.
I saw a demo of OV and thought it was going to big boost in productivity for getting an app up and running. Problem was, the programming language was based on spreadsheet commands, and there were no arrays(!). I worked in a 4GL back in those days called DataFlex (still around, btw) and it didn't have support for arrays, either.
Why would you design a programming language without array support?
I seem to recall a multitasking PC OS called WendesDOS, developed by a pair of brothers named Wendes back in the mid-80s. Microsoft bought them out and employed them, if I'm not mistaken. They use to have (small) ads in Infoworld, but I can't locate any info on it now.
I think you're neglecting economy of scale. If it cost $250 to build from scratch, prices will go down once component can be bought in bulk.
... I don't care if God exists. IMO, too much time, money and energy has been wasted on the topic. Time to move on.