DDSM (Doggie-doo Software Management)
The unpleasant and unintended stickiness of legacy software.
Example:
Manager: "Jim, you were the last person to work on X. I'm assigning this bug to you."
Jim: "This stinks!"
2020/09/13
Software and the Doggie Doo Effect
Does Microsoft Exist in a World Without People?
The Microsoft Windows lock screen features an ever-shifting series of landscapes, sometimes pastoral, sometimes of adventurous heights, or even famous landmarks (Stonehenge recently came up for me) but all of them have one thing in common: no people.
I don't know why. This could be intentional and they edit them out, perhaps worrying that people would be "disturbed" to see other people on their PC when they were logging in. It could be some massive self-selection process where early on, people just trained the AI serving these up that people-less pictures are preferable. Or perhaps that AI is sending the subtle message, "the world is better without you".
2018/12/16
Why Merging Software Products is Harder Than Expected
Recently a friend of mine told the story of in a small company that was acquired by a larger company with a competing product. The idea being "to take the best parts of both products" and make something better. Ten years later, that had not happened, and in fact technical issues plus tensions between the two product teams, pretty much ensured it never would.
At one of my previous companies, something similar unfolded. The company had two tiers of products for the same market. One was high-end and very expensive, the other was the lower-cost alternative. Both were very mature products and as you might expect, over time functionality converged a bit, as the high-end product extended into features suitable for smaller customers, while the low-end product expanded its offering. Each product had its own strengths and weaknesses.
Management noticed that and said, "hey, these two products do a lot of the same things, why not combine them and get the best of both worlds?" They filled a chart board with post-its showing the commonalities between the products. Each post-it contained words like "generates reports", and "computes portfolio balances". Never mind that each post-it encapsulated big piles of bespoke code that had only ever talked to post-its within the same product.
This is a bit like some big manufacturer saying,"we build trains, and we build buses, and they both do similar things -- moving people and stuff around. The great thing about a bus is that it can go anywhere there is a street. Trains can only go where the tracks have been laid, but they have a much greater capacity, better energy efficiency, and can be customized out of modular components. What if we take the best of a bus and the best of a train, and put them together? We change out the wheels and we have a tra-bus that can go anywhere! And the bus windows are much nicer, they're bigger and people can open them. Let's put those on."
And so it goes, until you have an incredibly ugly train-like thing built on a bus frame, that isn't street legal, that can't use existing modules (railcars) and now it needs more engines and better brakes, and so on.
As incredibly bad as this idea is in (vehicular) hardware, it's even worse in software; with these bu-train monstrosities, the problems of connecting the disparate parts are physical and easy to visualize.
In software, its too easy to lose sight of how parts fit together, and the possibilities are unbounded (blocking API, async API, restful API, redirected I/O, mapped memory, named pipes, sockets, protocols built on sockets, databases, data files, etc). Also, the parts can be written in entirely different languages that have trouble talking to each other. It doesn't even have to be different languages to be hard. Combining C++ written for Windows with C++ written for any other operating system can be insanely difficult. The challenges of integrating software products are enormous, and easy to grossly underestimate if you just break the product down into a bunch of functional boxes scribbled on post-its and say "hey, most of these boxes do the same thing!" If you see management doing something like that, its either time to speak up, or time to update your LinkedIn profile.
At one of my previous companies, something similar unfolded. The company had two tiers of products for the same market. One was high-end and very expensive, the other was the lower-cost alternative. Both were very mature products and as you might expect, over time functionality converged a bit, as the high-end product extended into features suitable for smaller customers, while the low-end product expanded its offering. Each product had its own strengths and weaknesses.
Management noticed that and said, "hey, these two products do a lot of the same things, why not combine them and get the best of both worlds?" They filled a chart board with post-its showing the commonalities between the products. Each post-it contained words like "generates reports", and "computes portfolio balances". Never mind that each post-it encapsulated big piles of bespoke code that had only ever talked to post-its within the same product.
This is a bit like some big manufacturer saying,"we build trains, and we build buses, and they both do similar things -- moving people and stuff around. The great thing about a bus is that it can go anywhere there is a street. Trains can only go where the tracks have been laid, but they have a much greater capacity, better energy efficiency, and can be customized out of modular components. What if we take the best of a bus and the best of a train, and put them together? We change out the wheels and we have a tra-bus that can go anywhere! And the bus windows are much nicer, they're bigger and people can open them. Let's put those on."
And so it goes, until you have an incredibly ugly train-like thing built on a bus frame, that isn't street legal, that can't use existing modules (railcars) and now it needs more engines and better brakes, and so on.
As incredibly bad as this idea is in (vehicular) hardware, it's even worse in software; with these bu-train monstrosities, the problems of connecting the disparate parts are physical and easy to visualize.
In software, its too easy to lose sight of how parts fit together, and the possibilities are unbounded (blocking API, async API, restful API, redirected I/O, mapped memory, named pipes, sockets, protocols built on sockets, databases, data files, etc). Also, the parts can be written in entirely different languages that have trouble talking to each other. It doesn't even have to be different languages to be hard. Combining C++ written for Windows with C++ written for any other operating system can be insanely difficult. The challenges of integrating software products are enormous, and easy to grossly underestimate if you just break the product down into a bunch of functional boxes scribbled on post-its and say "hey, most of these boxes do the same thing!" If you see management doing something like that, its either time to speak up, or time to update your LinkedIn profile.
Inverting the emulation stack as a thought exercise
The very first processor I worked on as a software professional was the Motorola 6800, an 8-bit processor that could access 64K of RAM with a clock rate of 1-Mhz. The machines I worked on had less memory, and everything was done in assembly (of course).
Today I'm working on a Windows machine with a 64-bit, 4 core processor clocking 2.8 Ghz, and accessing... well, its Moore's Law in action.
Would it be possible to write a AMD64 emulator on the 6800? I don't think it can be done within the RAM of the processor. Given the complexity of a modern core, more code may be needed to emulate the instruction set than will fit in 64K. Restricting the code to a subset (off-boarding floating point, for example) might help it squeak by, and we would not implement many internal features such as instruction reordering or prefetch.
So.. if it takes a couple hundred 6800 instructions to emulate one x64 instruction (on average) and the 6800 runs at 2 MHz, and emulation doesn't require any I/O to a file system, then the emulated x64 would be executing about 5K x64 instructions a second, or "only" a 400K to 1 slowdown.
Today I'm working on a Windows machine with a 64-bit, 4 core processor clocking 2.8 Ghz, and accessing... well, its Moore's Law in action.
Would it be possible to write a AMD64 emulator on the 6800? I don't think it can be done within the RAM of the processor. Given the complexity of a modern core, more code may be needed to emulate the instruction set than will fit in 64K. Restricting the code to a subset (off-boarding floating point, for example) might help it squeak by, and we would not implement many internal features such as instruction reordering or prefetch.
So.. if it takes a couple hundred 6800 instructions to emulate one x64 instruction (on average) and the 6800 runs at 2 MHz, and emulation doesn't require any I/O to a file system, then the emulated x64 would be executing about 5K x64 instructions a second, or "only" a 400K to 1 slowdown.
2018/10/15
Science vs Economics
An important aspect of good computer science is understanding the root causes for bad behavior in a system. Without a deep understanding, hacking around the problem often leads to bigger problems down the road. The original problem was not addressed, and the workaround can easily introduce unintended side effects or new errors.
Similar rigor is true for hard sciences like biology, chemistry, and physics. Einstein's famous theorems could be seen as an evaluation of the root causes for physical phenomena that didn't agree with classical physics.
This doesn't happen with economics. Case in point: economists point to the start of the Great Recession to 2008, when the acceleration in mortgage failures could no longer be ignored. However, the root causes for those failures can be traced much further back, like the repeal of Glass-Stiegal in the 1990s, Greenspun's lackadaisical and obfuscatory management of the Fed, the lack of regulation of the mortgage industry that followed, corruption across the board in the finance industruy, including regulators, the de-fanging of the STC and so on.
The failure to dig into root causes is one of the things that constrains the utility of economics (pun intended). Another is its dependence on the notion of people as rational actors, but at least this problem is being addressed to some degree by the field of behavioral economics. But perhaps this is optimistic.
Illustrating this blindness to root causes is an interview of Neel Kashkari, where he says he bought a house in California in 2005, and "didn't see it coming." I found this stunning. I was shopping for a home in California in 2005, and everything was screaming "this is insanity!" Ads on the radio for insane loan offers, home prices outstripping every other economic indicator, a dentist I met who was doing interest-only loans and laddering up into ever-more expensive zipcodes, and who thought he was a genius. It. Was. Nuts. The writing was on the wall, in wall-tall letters.
The best part, the truly best part is that guys like Kashkari take credit for turning things around, but did they really do anything to improve the odds of against future financial disasters? Like, some perp walks for the greedheads who almost destroyed the world's economy? Or a serious restructuring of the financial industry to counter the centralization of wealth and power? Ironic scornful laughter ensues.
Similar rigor is true for hard sciences like biology, chemistry, and physics. Einstein's famous theorems could be seen as an evaluation of the root causes for physical phenomena that didn't agree with classical physics.
This doesn't happen with economics. Case in point: economists point to the start of the Great Recession to 2008, when the acceleration in mortgage failures could no longer be ignored. However, the root causes for those failures can be traced much further back, like the repeal of Glass-Stiegal in the 1990s, Greenspun's lackadaisical and obfuscatory management of the Fed, the lack of regulation of the mortgage industry that followed, corruption across the board in the finance industruy, including regulators, the de-fanging of the STC and so on.
The failure to dig into root causes is one of the things that constrains the utility of economics (pun intended). Another is its dependence on the notion of people as rational actors, but at least this problem is being addressed to some degree by the field of behavioral economics. But perhaps this is optimistic.
Illustrating this blindness to root causes is an interview of Neel Kashkari, where he says he bought a house in California in 2005, and "didn't see it coming." I found this stunning. I was shopping for a home in California in 2005, and everything was screaming "this is insanity!" Ads on the radio for insane loan offers, home prices outstripping every other economic indicator, a dentist I met who was doing interest-only loans and laddering up into ever-more expensive zipcodes, and who thought he was a genius. It. Was. Nuts. The writing was on the wall, in wall-tall letters.
The best part, the truly best part is that guys like Kashkari take credit for turning things around, but did they really do anything to improve the odds of against future financial disasters? Like, some perp walks for the greedheads who almost destroyed the world's economy? Or a serious restructuring of the financial industry to counter the centralization of wealth and power? Ironic scornful laughter ensues.
2017/01/10
Breaking Out
Maybe I should write a Chrome plugin that deliberately makes the browsing experience so painful, you'll want to do just about anything else.
Advanced feature: Whitelist certain sites and certain hours (would still like to get work done). But this should be difficult to do, with prompts that keep asking "do you really want to do this?" and "Are you sure this isn't a site that's a mind-numbing time suck that's trying to hoover all your private data?"
Advanced feature: Whitelist certain sites and certain hours (would still like to get work done). But this should be difficult to do, with prompts that keep asking "do you really want to do this?" and "Are you sure this isn't a site that's a mind-numbing time suck that's trying to hoover all your private data?"
2016/12/24
Car talk
Scene: a couple is conversing at an outdoor table for a restaurant. A large SUV starts up a couple feet away. Conversation continues for a while. The SUV doesn't move, its engine still running.
The couple have to raise their voices, then begin to complain about the SUV and its driver. It should be illegal to just sit there and let the engine idle, especially near people trying to eat. They speculate about what the driver could be doing that's so important.
CUT to the SUV interior. Looking forward over the driver's shoulder. The dining couple is framed in the windshield. The driver is watching a youtube video on his phone about how to back back his SUV out of a parking space.
The video is in the middle of a checklist of what to do: check side mirrors and rear view mirror for obstructions. Check left and righ for oncoming traffic. Put car in reverse. If you have a manual transmission, see this other video.
Driver can't keep up with instructions, especially confused by the manual transmission bit. Rewinds the video, gets a commercial for the SUV.
CUT to the diners. I could ask him to move. No don't do that, people who drive cars like that always carry guns. We could move to another table. Maybe he'll leave soon.
CUT to SUV. Commercial has ended, the checklist has begun again. Start the engine. Driver complies, and gets a horrible grinding noise, since the engine is already running. Driver winces, couple winces, mutter not-nice things.
CUT do diners. He's got to leave soon. You think so, I mean its like he doesn't know how to drive or something.
CUT to SUV: driver rapidly spins head around as he gets through the "check mirrors" part of the video, at the manual transmission part, he pauses the video and thinks for a moment. He presses a couple buttons and says "Okay google, how do I tell if I have manual transmission?"
Eventually the SUV lurches away.
============================
Robot cars an end to vehicular crimes?
Bank robber with a gun and a bundle of loot jumps into his robot car, yells go go go! "Where to?" Anywhere. North! Go north!" The car activates its turn signal and smoothly, slowly pulls into traffic.
"Faster!"
"We have reached the speed limit, sir!" says the car, in an annoyingly perky voice. Sirens grow in the background.
"Turn left up here!"
"I can't do that, left turns are not permitted at this intersection."
"Then go faster!"
"We have reached the maximum speed limit. A faster speed will require emergency authorization."
"This is an emergency, go faster!"
"Yes sir. Increasing speed. I have also notified the authorities that we have an emergency, and am sending them our location and projected route."
The couple have to raise their voices, then begin to complain about the SUV and its driver. It should be illegal to just sit there and let the engine idle, especially near people trying to eat. They speculate about what the driver could be doing that's so important.
CUT to the SUV interior. Looking forward over the driver's shoulder. The dining couple is framed in the windshield. The driver is watching a youtube video on his phone about how to back back his SUV out of a parking space.
The video is in the middle of a checklist of what to do: check side mirrors and rear view mirror for obstructions. Check left and righ for oncoming traffic. Put car in reverse. If you have a manual transmission, see this other video.
Driver can't keep up with instructions, especially confused by the manual transmission bit. Rewinds the video, gets a commercial for the SUV.
CUT to the diners. I could ask him to move. No don't do that, people who drive cars like that always carry guns. We could move to another table. Maybe he'll leave soon.
CUT to SUV. Commercial has ended, the checklist has begun again. Start the engine. Driver complies, and gets a horrible grinding noise, since the engine is already running. Driver winces, couple winces, mutter not-nice things.
CUT do diners. He's got to leave soon. You think so, I mean its like he doesn't know how to drive or something.
CUT to SUV: driver rapidly spins head around as he gets through the "check mirrors" part of the video, at the manual transmission part, he pauses the video and thinks for a moment. He presses a couple buttons and says "Okay google, how do I tell if I have manual transmission?"
Eventually the SUV lurches away.
============================
Robot cars an end to vehicular crimes?
Bank robber with a gun and a bundle of loot jumps into his robot car, yells go go go! "Where to?" Anywhere. North! Go north!" The car activates its turn signal and smoothly, slowly pulls into traffic.
"Faster!"
"We have reached the speed limit, sir!" says the car, in an annoyingly perky voice. Sirens grow in the background.
"Turn left up here!"
"I can't do that, left turns are not permitted at this intersection."
"Then go faster!"
"We have reached the maximum speed limit. A faster speed will require emergency authorization."
"This is an emergency, go faster!"
"Yes sir. Increasing speed. I have also notified the authorities that we have an emergency, and am sending them our location and projected route."
Subscribe to:
Posts (Atom)