Why the insult? I've seen the complete process integrated for quite complex software, but at significant expense. I've also seen the integration go horribly wrong, also at great expense.
Heck, most shops still use the model of "yell at people who break the build" which hardly scales at all, or have great automation to keep the build healthy, but ignore the fact that's useless unless you also pass some basic set of tests that show the build is worth anyone's time to do more with.
are only so many ways one can shape and join wood. Whatever tools you pick the desired outcome is the same, its the degree of success that varies
Do you know the original term "hacker"? It's a craftsman who makes furniture with a hatchet. It's a skill like nothing else in carpentry. And sandpaper is, actually, incompatible (the nifty thing about the hatchet approach is it leaves wood smoother than you can get with sandpaper, odd as that sounds).
Most high end furniture today is actually made mostly with a glue gun and xacto knife, oddly enough. No clue why, but beautiful veneers and gold leaf (sometimes so thin you can't actually use the furniture) and so on over MDF fetches the highest prices these days, and that too is its own quite district skill set.
Don't make the "management mistake" of assuming something is simple or easy because you don't understand it.
This might be an extension of that. That's just a way to encapsulate a remote/delayed function call - think using one object down and back up the entire stack (which may be across several machines in a distributed environment). Though it would be better to say the pattern is a simplified version of this much older idea.:)
Thanks - I call that "configuration information", but yeah, when the data really is external and more or les stable, I like that approach.
But sometimes you just have 100 work items, each of which has 20 properties, and each layer you'll call through will gradually transform those into 30 low-level concepts and then finally the work will get done. Having a "data class" separate from your stack of "processing classes" there makes sense.
I haven't heard of a "dynamic environments" as a coding pattern, and its a hard phrase to Google, as it combines two popular buzzwords. Care to elaborate?
A good craftsman can get by with suboptimal tools.
A good craftsman is not content to "get by", almost by definition. If some part of your workflow sucks, you make it better, whether that's a better tool or more skill/training. If you're good, you never stop improving (until management forces BS on you, of course).
No amount of training wheels is going to make complex programming significantly easier.
True enough, but I could do without the razor blades on the seat and handles. But my complaints are generally with the toolchain beyond the code. I so often get forced to use tools that are just crap, or tools that are good but poorly implemented. Surely it's mathematically possible to have a single good, integrated system that does source control with easy branch-and-merge, bug and backlog tracking and management, and code reviews, and test automation and testcase tracking, and that doesn't look and perform like an intern project!
There are good point solutions to each of those problems, sure, but the whole process from "I think this fix is right and it's passed code review" to: the main branch has been built and tested with this fix in place, therefore the change has been accepted into the branch, therefore the bug is marked fixed and the code review closed, and there's some unique ID that links all of them together for future reference - that process should all be seamless, painless, and easy. But the amount of work that takes to tie all the good point products together, repeated at every dev shop, is just nuts, and usually half done.
I hear the California government has a bill to rename the San Andreas Fault to "Bush's Fault", just so they never have to stop using the phrase! But that may be just a rumor...
Well said. Heck, even with buggy or poorly-documented libraries, trial-and-error is just the starting place, because you can't discover the corner cases that way. Sometimes you just have to step through the object code with a debugger to find all the branches-not-takes from your trial, to document how it really works. Sucks to have to do it, but that's work for you.
There's nothing worse than discovering you're stuck with a co-worker who's a trial-and-error "programmer", as you know he'll never understand the best practices and you'll be stuck cleaning up after him every release.
The point of that proverb is that a good craftsman chose his tools to begin with, so he has only himself to blame. Programming is odd in that you have bad toolchains forced on you by management - tools you know are bad, know will cause more problems than their worth, but they're a corporate standard or some such BS. Usually not bad enough to be worth quitting over, so you hobble along.
Of course, I did quit a job once primarily because we had Rational Rose forced on us from above (but mostly because a management that would do that would do anything).
and sometimes the "right" way to code something is tedious and unusable, involving passing state down through several layers of method parameters
Sometimes that really is the right way (more often it's a sign you've mixed your plumbing with your business logic inappropriately, but that's another topic). One old-school technique that has inappropriately fallen out of favor is the "comreg" (communication region). In modern terms: take all the parameters that all the layers need (which are mostly redundant), and toss them together in a struct and pass the struct "from hand to hand", fixing a the right bit in each layer.
It seems like a layer violation, but only because "layers" are sometimes just the wrong metaphor. Sometimes an assembly line is a better metaphor. You have a struct with a jumble of fields that contain the input at the start and the result at the end and a mess in the middle. You can always stick a bunch of interfaces in front of the struct if it makes you feel better, one for each "layer".
One place this pattern shines is when you're passing a batch of N work items through the layers in a list/container. This allows for the best error handling and tracking, while preserving whatever performance advantage working in batches gave you - each layer just annotates the comreg struct with error info for any errors, and remaining layers just ignore that item and move to the next in the batch. Errors can then be reported back to the caller in a coherent way, and all the non-error work still gets done.
The tea party successfully primaried-out some long-standing incumbents. While I fear they're being fully absorbed by the establishment, it shows it's possible.
Really, democracy works great for things the voters care about. The modern obstacle to democracy is the modern governments full focus over keeping the voters complacent at all costs. This is why I fear we'll have an entitlement bubble - we could have begun a soft landing a few years back, but hey, there's no crisis, right? Only a big greedy meanie would suggest reducing spending when the world won't end tomorrow if you don't! It will be a hard landing now, I fear.
One of the toughest lessons I've had to teach clients is that the motivations of attackers may not make any sense to you. In fact they probably won't.
Indeed: "all politics is local". People have a hard time understanding this. Why does someone launch a terrorist attack against the US? It will be something involving the people that they socialize with, and the usual motivations of status, respect, dignity and so on. It may in some very distant way be a response to US actions, but don't look for direct "they killed my parents, and I've spent my life seeking the six-fingered man" motivations.
When attacks (cyber or otherwise) are local, motivations are usually straightforward and understandable, but when the target is very distant, it will be something that makes a lot of sense in the attackers' community, but with the distance in geography and culture, it can be totally opaque to you. There may be nothing you can do to not be the target of choice, if you're successful and well known like a media property. No, they don't hate you because you're successful, but their distant community knows you exist and you thus give them bragging rights because you're successful.
Don't conflate accidents with predictable consequences. Drunk drivers is the better analogy. And driving drunk is, in fact, a serious crime. As is selling arms to the cartels.
Why are you even trying to defend actions like this? Are you so enamored of some political party that you'll bend over backwards to defend their most egregious actions? Don't be that guy - every political party will fuck you sideways for a laugh; none of them deserve any loyalty.
Both code and yeast have deterministic underpinnings. But at scale both can only be modeled statistically. Sure, it's way easier to get a billion yeast cells than a billion customers, so you get there faster, but I'm working with software at the billion-user scale now and, well, we do a lot of statistics.
Sure, specific bugs get identified and fixed and you hope the bug fix spreads fast (and you have some control over that), but the same is true with yeast mutations.
The only reason anyone cares about Monsanto IP is that the products are better (unless you have the luxury of organic). If the farmer didn't come out ahead by buying Monsanto seed, he wouldn't bother.
But if Monsanto were as profitable as you seem to imagine, it would have several competitors each with it's own IP. Look at their finances: good by the standards of heavy industry, but terrible by the standards of an "IP company". Eh, they employ 20,000 people, and they do OK but not great. Not the evil overlord at all, really.
Illegal arms brokers are quick with that line. It may even be true. But that doesn't make it any less immoral to be the one doing it. We should not be the ones doing it.
Lots of cities are like that in the US these days. Sad, really. And that's not even including Detroit, which is starting to look like a Mad Max movie.
I looked at the Tesla before I bought my current car, but the Tesla isn't really a luxury sedan despite the price (nice ride, though). One important consideration for me was practical wheel size and ground clearance. I don't need offroad tires, but a ~50 tire aspect ratio and reasonable ground clearance let you take pot holes and stupidly-steep ramps from streets to parking lots at a reasonable speed without fear of damage.
Ribbon-thin tires are just asking for trouble. Plus even the rap songs acknowledge "rims too big make the ride too hard".
Why is the church involved here? Did someone ask the pope to step down?
Seriously, it's the eHarmony verdict. Maybe you don't know that one? eHarmony is a somewhat-religious online dating service that only does hetreo matchups. They claim the highest marriage rate of any online service. They were sued to force them to do same-sex matchups. The CEO said basically "look, our service isn't a scam, we have real knowhow here around how we do matchups, and we have nothing to contribute for same-sex matchups". But they were forced to provide such a service anyhow. And of course no one used it, not even the person who started the lawsuit. It was just a culture war.
The religious right took this to heart. "We can now be compelled by the state against our conscience or even ability to perform services for gays that we perform for church members." Churches that don't marry gays are (IMO legitimately) worried about being forced by law to do so.
The other concern on the right, which the left doesn't seem to grok, is that "we have this proven system for transmitting culture to future generations, and a way of rewarding socially people who comply with that". They see gay marriage as stripping the incentive to do it right. As a conservative engineer I take their point: I distrust unproven new systems even though I can't see any problems with them on paper. But IMO anything that results in children raised by committed couples is a good thing, so hopefully it all works out that way.
Slashdot Mirror
Well, 200 is high, but most successful software products in the world have dev teams of about 100. And with a good toolchain that's not a problem.
Why the insult? I've seen the complete process integrated for quite complex software, but at significant expense. I've also seen the integration go horribly wrong, also at great expense.
Heck, most shops still use the model of "yell at people who break the build" which hardly scales at all, or have great automation to keep the build healthy, but ignore the fact that's useless unless you also pass some basic set of tests that show the build is worth anyone's time to do more with.
are only so many ways one can shape and join wood. Whatever tools you pick the desired outcome is the same, its the degree of success that varies
Do you know the original term "hacker"? It's a craftsman who makes furniture with a hatchet. It's a skill like nothing else in carpentry. And sandpaper is, actually, incompatible (the nifty thing about the hatchet approach is it leaves wood smoother than you can get with sandpaper, odd as that sounds).
Most high end furniture today is actually made mostly with a glue gun and xacto knife, oddly enough. No clue why, but beautiful veneers and gold leaf (sometimes so thin you can't actually use the furniture) and so on over MDF fetches the highest prices these days, and that too is its own quite district skill set.
Don't make the "management mistake" of assuming something is simple or easy because you don't understand it.
This might be an extension of that. That's just a way to encapsulate a remote/delayed function call - think using one object down and back up the entire stack (which may be across several machines in a distributed environment). Though it would be better to say the pattern is a simplified version of this much older idea. :)
Thanks - I call that "configuration information", but yeah, when the data really is external and more or les stable, I like that approach.
But sometimes you just have 100 work items, each of which has 20 properties, and each layer you'll call through will gradually transform those into 30 low-level concepts and then finally the work will get done. Having a "data class" separate from your stack of "processing classes" there makes sense.
I haven't heard of a "dynamic environments" as a coding pattern, and its a hard phrase to Google, as it combines two popular buzzwords. Care to elaborate?
A good craftsman can get by with suboptimal tools.
A good craftsman is not content to "get by", almost by definition. If some part of your workflow sucks, you make it better, whether that's a better tool or more skill/training. If you're good, you never stop improving (until management forces BS on you, of course).
No amount of training wheels is going to make complex programming significantly easier.
True enough, but I could do without the razor blades on the seat and handles. But my complaints are generally with the toolchain beyond the code. I so often get forced to use tools that are just crap, or tools that are good but poorly implemented. Surely it's mathematically possible to have a single good, integrated system that does source control with easy branch-and-merge, bug and backlog tracking and management, and code reviews, and test automation and testcase tracking, and that doesn't look and perform like an intern project!
There are good point solutions to each of those problems, sure, but the whole process from "I think this fix is right and it's passed code review" to: the main branch has been built and tested with this fix in place, therefore the change has been accepted into the branch, therefore the bug is marked fixed and the code review closed, and there's some unique ID that links all of them together for future reference - that process should all be seamless, painless, and easy. But the amount of work that takes to tie all the good point products together, repeated at every dev shop, is just nuts, and usually half done.
I knew it! It's Bush's Fault!
I hear the California government has a bill to rename the San Andreas Fault to "Bush's Fault", just so they never have to stop using the phrase! But that may be just a rumor ...
Well said. Heck, even with buggy or poorly-documented libraries, trial-and-error is just the starting place, because you can't discover the corner cases that way. Sometimes you just have to step through the object code with a debugger to find all the branches-not-takes from your trial, to document how it really works. Sucks to have to do it, but that's work for you.
There's nothing worse than discovering you're stuck with a co-worker who's a trial-and-error "programmer", as you know he'll never understand the best practices and you'll be stuck cleaning up after him every release.
Something something blames his tools.
The point of that proverb is that a good craftsman chose his tools to begin with, so he has only himself to blame. Programming is odd in that you have bad toolchains forced on you by management - tools you know are bad, know will cause more problems than their worth, but they're a corporate standard or some such BS. Usually not bad enough to be worth quitting over, so you hobble along.
Of course, I did quit a job once primarily because we had Rational Rose forced on us from above (but mostly because a management that would do that would do anything).
and sometimes the "right" way to code something is tedious and unusable, involving passing state down through several layers of method parameters
Sometimes that really is the right way (more often it's a sign you've mixed your plumbing with your business logic inappropriately, but that's another topic). One old-school technique that has inappropriately fallen out of favor is the "comreg" (communication region). In modern terms: take all the parameters that all the layers need (which are mostly redundant), and toss them together in a struct and pass the struct "from hand to hand", fixing a the right bit in each layer.
It seems like a layer violation, but only because "layers" are sometimes just the wrong metaphor. Sometimes an assembly line is a better metaphor. You have a struct with a jumble of fields that contain the input at the start and the result at the end and a mess in the middle. You can always stick a bunch of interfaces in front of the struct if it makes you feel better, one for each "layer".
One place this pattern shines is when you're passing a batch of N work items through the layers in a list/container. This allows for the best error handling and tracking, while preserving whatever performance advantage working in batches gave you - each layer just annotates the comreg struct with error info for any errors, and remaining layers just ignore that item and move to the next in the batch. Errors can then be reported back to the caller in a coherent way, and all the non-error work still gets done.
That's irrelephant!
The tea party successfully primaried-out some long-standing incumbents. While I fear they're being fully absorbed by the establishment, it shows it's possible.
Really, democracy works great for things the voters care about. The modern obstacle to democracy is the modern governments full focus over keeping the voters complacent at all costs. This is why I fear we'll have an entitlement bubble - we could have begun a soft landing a few years back, but hey, there's no crisis, right? Only a big greedy meanie would suggest reducing spending when the world won't end tomorrow if you don't! It will be a hard landing now, I fear.
Well, your argument is this: Mexicans would be incapable of murdering as many people if we didn't give them guns.
Wow, you ignored every one of my posts to cling to this pre-conceived objection. No point is writing anything further then.
One of the toughest lessons I've had to teach clients is that the motivations of attackers may not make any sense to you. In fact they probably won't.
Indeed: "all politics is local". People have a hard time understanding this. Why does someone launch a terrorist attack against the US? It will be something involving the people that they socialize with, and the usual motivations of status, respect, dignity and so on. It may in some very distant way be a response to US actions, but don't look for direct "they killed my parents, and I've spent my life seeking the six-fingered man" motivations.
When attacks (cyber or otherwise) are local, motivations are usually straightforward and understandable, but when the target is very distant, it will be something that makes a lot of sense in the attackers' community, but with the distance in geography and culture, it can be totally opaque to you. There may be nothing you can do to not be the target of choice, if you're successful and well known like a media property. No, they don't hate you because you're successful, but their distant community knows you exist and you thus give them bragging rights because you're successful.
I've seen two news stories this week that made that mistake. It's going to be lose/loose all over again. *shudder*
Don't conflate accidents with predictable consequences. Drunk drivers is the better analogy. And driving drunk is, in fact, a serious crime. As is selling arms to the cartels.
Why are you even trying to defend actions like this? Are you so enamored of some political party that you'll bend over backwards to defend their most egregious actions? Don't be that guy - every political party will fuck you sideways for a laugh; none of them deserve any loyalty.
That information wasn't really obtained at any expense beyond the basic economic program expense
It's been demonstrated that federal agents were killed with these weapons. I call that fucking expensive.
Both code and yeast have deterministic underpinnings. But at scale both can only be modeled statistically. Sure, it's way easier to get a billion yeast cells than a billion customers, so you get there faster, but I'm working with software at the billion-user scale now and, well, we do a lot of statistics.
Sure, specific bugs get identified and fixed and you hope the bug fix spreads fast (and you have some control over that), but the same is true with yeast mutations.
The only reason anyone cares about Monsanto IP is that the products are better (unless you have the luxury of organic). If the farmer didn't come out ahead by buying Monsanto seed, he wouldn't bother.
But if Monsanto were as profitable as you seem to imagine, it would have several competitors each with it's own IP. Look at their finances: good by the standards of heavy industry, but terrible by the standards of an "IP company". Eh, they employ 20,000 people, and they do OK but not great. Not the evil overlord at all, really.
Corn: it filters carbon by isotope, despite chemical equivalence. What can't corn do?
Illegal arms brokers are quick with that line. It may even be true. But that doesn't make it any less immoral to be the one doing it. We should not be the ones doing it.
Lots of cities are like that in the US these days. Sad, really. And that's not even including Detroit, which is starting to look like a Mad Max movie.
I looked at the Tesla before I bought my current car, but the Tesla isn't really a luxury sedan despite the price (nice ride, though). One important consideration for me was practical wheel size and ground clearance. I don't need offroad tires, but a ~50 tire aspect ratio and reasonable ground clearance let you take pot holes and stupidly-steep ramps from streets to parking lots at a reasonable speed without fear of damage.
Ribbon-thin tires are just asking for trouble. Plus even the rap songs acknowledge "rims too big make the ride too hard".
Why is the church involved here? Did someone ask the pope to step down?
Seriously, it's the eHarmony verdict. Maybe you don't know that one? eHarmony is a somewhat-religious online dating service that only does hetreo matchups. They claim the highest marriage rate of any online service. They were sued to force them to do same-sex matchups. The CEO said basically "look, our service isn't a scam, we have real knowhow here around how we do matchups, and we have nothing to contribute for same-sex matchups". But they were forced to provide such a service anyhow. And of course no one used it, not even the person who started the lawsuit. It was just a culture war.
The religious right took this to heart. "We can now be compelled by the state against our conscience or even ability to perform services for gays that we perform for church members." Churches that don't marry gays are (IMO legitimately) worried about being forced by law to do so.
The other concern on the right, which the left doesn't seem to grok, is that "we have this proven system for transmitting culture to future generations, and a way of rewarding socially people who comply with that". They see gay marriage as stripping the incentive to do it right. As a conservative engineer I take their point: I distrust unproven new systems even though I can't see any problems with them on paper. But IMO anything that results in children raised by committed couples is a good thing, so hopefully it all works out that way.