"No business that likes money and wants to continue making money will be discriminating against anyone."
False. As a business owner with two business partners, we have refused to engage clients a few times. We do not do work for other companies that are involved in sex trade (e.g. porn producers), alcohol (e.g. bars), or gambling (e.g. gov't run lotteries). We do this for the reason that we think these things are damaging to society and we aren't willing to put money before the wellbeing of society. As a business this has been tough for us from time to time since we have to refuse revenue.
Other businesses might have other ways of discriminating. In fact, there are federal laws that enforce certain types of discrimination. For example arms trade to restricted countries. The people in those countries did not choose to be citizens there yet they are restricted from access to the best of American arms manufacturing. Shame on the U.S. for discriminating.
Fundamentally, we all discriminate. The only question is how much of that discrimination (and what categories) are embodied in our legal frameworks and in our social mores.
I started out with the same thing that a lot of other people have talked about: pretend to go along, be a bit (or a lot) stupid, mis-hear or mis-apply instructions, etc. Then, for some perfectly legitimate reason I coughed. Inspiration struck. I faked a heart attack even telling the guy I wasn't feeling good, making noises, and then pretending to fall and drop the phone for some real banging sounds. The guy on the other end of the line was so concerned he stayed on the line an extra five minutes without me saying a word. He hung up and then called back. I let it ring through to VM. I was chuckling for weeks afterwards.
Practical professional stuff to learn about: design patterns, refactoring and test-driven development. Start learning this stuff as soon as possible otherwise you'll make all kinds of awful mistakes when your doing your first professional gigs (assuming you get to that point).
Disclaimer: I work as a consultant for large and mid-size businesses.
My experience is that there is no magic bullet for quality, but that there are a few things you can do that will dramatically improve things. What Agile methods bring to this is that they provide fast feedback with customers and users. This means that if the team actually bothers to use the feedback, that they can produce things that have better customer and user perception of quality. Additionally, Agile engineering practices such as refactoring and test-driven development can be used to effectively prevent most technical quality problems. Agile borrows heavily from Lean thinking in which one of the ideas is to build quality in (instead of testing at the end). Lots of practices of Agile methods support this idea and, on rare occasions, I have seen Agile teams building complex systems with defect rates close to 1 or 2 low impact defects per year.
That said, the disciplines of waterfall thinking are often lost when an organization switches to Agile. These disciplines around deep analysis, seeing the big picture, etc. are all still important. They should be done differently with Agile, but they shouldn't be forgotten.
Unfortunately, most teams and organizations do neither waterfall nor Agile well. This is because management has a poor understanding of what it takes to properly support staff who are doing complex creative problem-solving work. Instead, management tries to control staff as if they were assembly-line robotic resources. Ultimately, to be effective with software development, management needs to treat software developers as each being unique, autonomous, and deeply valuable for their own talents, skills and experiences. Likewise, software developers have to stop treating customers and users as idiots... they're not. Agile methods, as a set of values and principles, are about changing these relationships to make them more healthy for everyone involved.
The military has a huge budget. Why not re-direct some of that to climate change reduction efforts? Solve the problem not the symptoms. Maybe it's because climate change is just another reason to grow budgets, grab more money... and perpetuate the system itself.
Backdoors, privacy laws, etc. etc. etc. are all about reacting to problems that have already happened. I wish people would recognize that we have a fundamental "spiritual" problem (not religious) which is that we need to learn to care about others. Any society that focuses on individual satisfaction and freedom is going to loose the balance with good social behaviour. "Save the children" is all about reaction to a society that fundamentally values the individual freedom too highly and over and above societal health. I think of this as spiritual because it is about our fundamental beliefs and feelings. Wouldn't it be much better if we could effectively educate everyone so that we all cared about each other? Our education systems focus on individual accomplishment and have only minimal support for service, teamwork and other activities and attitudes that would help educate us on supporting each other. In other words, preventing perversion through education.
For a lot of robotics work you need to be able to install software on the computer. Not sure if that would be a problem or not, but Arduino and Lego both require good access to the computer. Something like a Raspberry Pi or Oodo which is already a computer itself might be a better starting point if there are restrictions on accessing a host computer.
I did work in construction (and land surveying, and drafting, and other related fields) but only for a short time. So maybe I had no idea what I was doing... but that's actually the point of the article: software folks who want to use the construction analogy to come up with an "architect role" are doing something from a place of profound ignorance and the analogy is deeply flawed.
Lack of architecture is not the same as lack of an architect. Indeed, no architecture in a system == chaos. But how you get good architecture, unfortunately, is rarely from architects.
Oops. Meant to say "there was never a moment when all the applications weren't fully functional.
It's true that the old system(s) were a sort of guide, but it really was a complete replacement/re-architecture. Not only that, but there was no time in the project when we had a document that said "this is the current architecture". We had to do a lot of exploring along the way.
My job title prior to the project was architect but I told the CIO that it was unnecessary and so at the start of the project I was no longer the architect. We didn't have one. That said, there was a big team of us and we had lots of ongoing discussion about architecture - as we were building out the new systems. No doubt I influenced those discussions somewhat, but I certainly was no longer the authority.
I was the senior architect reporting to the CIO of Charles Schwab. I was responsible for huge systems at an architectural level. Then, with the permission of the CIO we launched a two year enterprise re-write covering hundreds of applications and dozens of technology platforms from old green-screen cobol systems to modern Java and.NET systems... and we did it with no up-front architecture. Pure Agile, with all the process and engineering practices to do it properly. Huge success because there was never a moment when all the applications were fully functional and there was never a formal switch-over. We re-wrote everything in-place.
Of course, I'm not saying that there was no research, that there was no good design thinking, or that we never thought about the future. But there was certainly no architect and there was not technical lead who had the final authority on the overall design or any particular detail.
I've seen this approach work with $20M projects and with $200K projects. I've seen it work and result in systems with zero defect rates extended over years. I've seen it work on systems with thousands of lines of code and systems with millions of lines of code. It's possible, it's just that most people have been so brainwashed by the construction analogy and "scientific management" thinking that it's hard to imagine that it's possible.
Yup!!! I think everyone building software should spend time supporting their software! This is part of what the software craftsmanship movement is about.
Thanks for the comments. I really appreciate your final comment! I'm a big proponent of good engineering practices over bureaucratic engineering processes!
True enough: the article on Kuro5hin is very old... I've often thought of writing an update to take in to account some of the things you mention. (Actually, it's hard to believe I wrote that 11 years ago!)
Still, I feel that most software architects really inflate the importance (and time) of their jobs. It's true that there is some amount of legitimate research to be done in exploring the broad outlines of your solution. However, most of the time those solutions are dreamed up by the architect in a few hours and then they spend months doing confirmatory biased research to flesh out the justifications for their original idea. That's the waste. As the plover said, all that knowledge about design patterns, etc. is still applicable. Just don't do it in a big up-front fashion.
I don't have a lot of patience with the profession since it's built on a fatally flawed analogy and all software architects ever do is waste and overhead from a lean perspective.
I'm not confused. I just assumed that people could make a small mental leap: Working software = (functionality + quality + ease of use) whereas comprehensive documentation = waste in order to accommodate for lake of ease of use or poor quality. I hoped that the functionality and quality part of working software would generally be understood without me needing to be pedantic.
I'm guessing that there aren't a lot of people on Slashdot who are both users and developers for Odoo / OpenERP. I am. I am also formerly a UX expert (late 90's, but I keep somewhat up-to-date), and I am currently an active developer and consultant. I have some very specific views on this based on my background.
1. In the Agile manifesto it says "Working software [is valued] over comprehensive documentation." That has always meant, to me, that UX takes priority over user documentation. I've seen Agile teams kick the snot out of competitors by focusing on UX and foregoing nearly all user documentation. When I say "nearly", I mean that a very high level (well written) orientation document, is sufficient.
2. For this system itself which is a complex ERP system, there are four levels of "documentation" possible: a) User Documentation b) Configuration Documentation c) Customization / Plug-in Developer's Documentation and d) Internal Development Documentation. Since Odoo is open-source, in a way, all of these levels are "user documentation".
3. UX absolutely needs to be the one and only factor in considering the end user experience of an already-configured system. There shouldn't be any need for an end user to go to a user manual unless an organization has done extensive configuration / customization (in which case that organization has the responsibility for the documentation, not the Odoo organization. Likewise, UX should be the main approach to making configuration easy, but there may be some scenario-based examples documented to help orient those who are doing the configuration. These are your day-to-day admin users. The marketing automation module is a good example of where UX sucks and the documentation is poor. Given the choice, I would much prefer the UX to be improved!
4. For customization and internal development, there is still a role for UX to play, but (knowing the actual state of the documentation) you must improve that documentation dramatically. It is sparse and hard to follow, hard to find the right information, and often has very old / outdated screenshots. Although what information there is seems to be accurate, there are often huge gaps, and many undocumented api's and options. I know this because I have had to struggle through creating custom modules by reading through reams of source code in other modules. Love that it's open source, hate the quality of the developer documentation:-)
Lastly, Dr. Amit Goswami, Ph.D., theoretical nuclear physicist
And a theoretical nuclear physicist is more qualified than biologists like Coyle and Dawkins to write about evolution because... ?
That's a veiled ad hominum argument - a logical fallacy. Just like you have asserted that someone should read Coyle and Dawkins, you in turn might consider setting an example by examining the arguments of Dr. Goswami.
FWIW, I haven't read any of these references, but I have read extensively on all sides of the argument including evolutionary biologists, intelligent design proponents and other non-standard models for what we observe. I've read other Dawkins books and found them to be just as weak as many of the ID books. As far as I can tell, it's all still philosophy, and the science that we have, namely molecular biology, breeding and the fossil record do not show evolution as the conclusive final word on how life works.
I have no idea if this would help, but with developments in solar technology, would it make a significant difference if the tops of the wings, fuselage, tail and fan ducts were all solar panels? Seems like a simple thing to do to help with range... maybe not done because it's not reliable.
I've been faced with this kind of decision a number of times. I always remember: if I'm not filthy stinking rich right now, then I'm probably bad at predicting the future. Any attempt to do so should be taken with a huge dose of scepticism.
That said, I think that the practical answer is simple: invest a bit of time doing a bake-off of the likely candidates. Try to choose some real high-priority business features, and then get very small teams of 2 or 3 people each to use each of the frameworks to build production-quality functionality for those business features. Don't take more than a week to do this. To use your example, Flex vs. HTML5, you would get two small teams to try to build the _same_ functionality using the two different frameworks.
Evaluate your results based on how much the teams actually got done. (Remember: production quality, not prototype quality.)
Since you can't predict the future, I also strongly recommend good Agile Engineering Practices to help to build a system that is not just change-tolerant, but is actually easy to change.
Slashdot Mirror
"No business that likes money and wants to continue making money will be discriminating against anyone."
False. As a business owner with two business partners, we have refused to engage clients a few times. We do not do work for other companies that are involved in sex trade (e.g. porn producers), alcohol (e.g. bars), or gambling (e.g. gov't run lotteries). We do this for the reason that we think these things are damaging to society and we aren't willing to put money before the wellbeing of society. As a business this has been tough for us from time to time since we have to refuse revenue.
Other businesses might have other ways of discriminating. In fact, there are federal laws that enforce certain types of discrimination. For example arms trade to restricted countries. The people in those countries did not choose to be citizens there yet they are restricted from access to the best of American arms manufacturing. Shame on the U.S. for discriminating.
Fundamentally, we all discriminate. The only question is how much of that discrimination (and what categories) are embodied in our legal frameworks and in our social mores.
Totally amazing! I love it!!! I'm going to have to use it in a song.
I started out with the same thing that a lot of other people have talked about: pretend to go along, be a bit (or a lot) stupid, mis-hear or mis-apply instructions, etc. Then, for some perfectly legitimate reason I coughed. Inspiration struck. I faked a heart attack even telling the guy I wasn't feeling good, making noises, and then pretending to fall and drop the phone for some real banging sounds. The guy on the other end of the line was so concerned he stayed on the line an extra five minutes without me saying a word. He hung up and then called back. I let it ring through to VM. I was chuckling for weeks afterwards.
This might be interesting for people: Enterprise Agility - Pragmatic or Transformative.
Practical professional stuff to learn about: design patterns, refactoring and test-driven development. Start learning this stuff as soon as possible otherwise you'll make all kinds of awful mistakes when your doing your first professional gigs (assuming you get to that point).
LOL!!! Although I have to say, that even learning _about_ homeopathy would probably be a good idea... just to avoid it.
For wanting to learn something.
Disclaimer: I work as a consultant for large and mid-size businesses.
My experience is that there is no magic bullet for quality, but that there are a few things you can do that will dramatically improve things. What Agile methods bring to this is that they provide fast feedback with customers and users. This means that if the team actually bothers to use the feedback, that they can produce things that have better customer and user perception of quality. Additionally, Agile engineering practices such as refactoring and test-driven development can be used to effectively prevent most technical quality problems. Agile borrows heavily from Lean thinking in which one of the ideas is to build quality in (instead of testing at the end). Lots of practices of Agile methods support this idea and, on rare occasions, I have seen Agile teams building complex systems with defect rates close to 1 or 2 low impact defects per year.
That said, the disciplines of waterfall thinking are often lost when an organization switches to Agile. These disciplines around deep analysis, seeing the big picture, etc. are all still important. They should be done differently with Agile, but they shouldn't be forgotten.
Unfortunately, most teams and organizations do neither waterfall nor Agile well. This is because management has a poor understanding of what it takes to properly support staff who are doing complex creative problem-solving work. Instead, management tries to control staff as if they were assembly-line robotic resources. Ultimately, to be effective with software development, management needs to treat software developers as each being unique, autonomous, and deeply valuable for their own talents, skills and experiences. Likewise, software developers have to stop treating customers and users as idiots... they're not. Agile methods, as a set of values and principles, are about changing these relationships to make them more healthy for everyone involved.
The military has a huge budget. Why not re-direct some of that to climate change reduction efforts? Solve the problem not the symptoms. Maybe it's because climate change is just another reason to grow budgets, grab more money... and perpetuate the system itself.
Backdoors, privacy laws, etc. etc. etc. are all about reacting to problems that have already happened. I wish people would recognize that we have a fundamental "spiritual" problem (not religious) which is that we need to learn to care about others. Any society that focuses on individual satisfaction and freedom is going to loose the balance with good social behaviour. "Save the children" is all about reaction to a society that fundamentally values the individual freedom too highly and over and above societal health. I think of this as spiritual because it is about our fundamental beliefs and feelings. Wouldn't it be much better if we could effectively educate everyone so that we all cared about each other? Our education systems focus on individual accomplishment and have only minimal support for service, teamwork and other activities and attitudes that would help educate us on supporting each other. In other words, preventing perversion through education.
For a lot of robotics work you need to be able to install software on the computer. Not sure if that would be a problem or not, but Arduino and Lego both require good access to the computer. Something like a Raspberry Pi or Oodo which is already a computer itself might be a better starting point if there are restrictions on accessing a host computer.
I did work in construction (and land surveying, and drafting, and other related fields) but only for a short time. So maybe I had no idea what I was doing... but that's actually the point of the article: software folks who want to use the construction analogy to come up with an "architect role" are doing something from a place of profound ignorance and the analogy is deeply flawed.
Lack of architecture is not the same as lack of an architect. Indeed, no architecture in a system == chaos. But how you get good architecture, unfortunately, is rarely from architects.
Oops. Meant to say "there was never a moment when all the applications weren't fully functional.
It's true that the old system(s) were a sort of guide, but it really was a complete replacement/re-architecture. Not only that, but there was no time in the project when we had a document that said "this is the current architecture". We had to do a lot of exploring along the way.
My job title prior to the project was architect but I told the CIO that it was unnecessary and so at the start of the project I was no longer the architect. We didn't have one. That said, there was a big team of us and we had lots of ongoing discussion about architecture - as we were building out the new systems. No doubt I influenced those discussions somewhat, but I certainly was no longer the authority.
Great article! Thanks!
I was the senior architect reporting to the CIO of Charles Schwab. I was responsible for huge systems at an architectural level. Then, with the permission of the CIO we launched a two year enterprise re-write covering hundreds of applications and dozens of technology platforms from old green-screen cobol systems to modern Java and .NET systems... and we did it with no up-front architecture. Pure Agile, with all the process and engineering practices to do it properly. Huge success because there was never a moment when all the applications were fully functional and there was never a formal switch-over. We re-wrote everything in-place.
Of course, I'm not saying that there was no research, that there was no good design thinking, or that we never thought about the future. But there was certainly no architect and there was not technical lead who had the final authority on the overall design or any particular detail.
I've seen this approach work with $20M projects and with $200K projects. I've seen it work and result in systems with zero defect rates extended over years. I've seen it work on systems with thousands of lines of code and systems with millions of lines of code. It's possible, it's just that most people have been so brainwashed by the construction analogy and "scientific management" thinking that it's hard to imagine that it's possible.
Yup!!! I think everyone building software should spend time supporting their software! This is part of what the software craftsmanship movement is about.
Thanks for the comments. I really appreciate your final comment! I'm a big proponent of good engineering practices over bureaucratic engineering processes!
True enough: the article on Kuro5hin is very old... I've often thought of writing an update to take in to account some of the things you mention. (Actually, it's hard to believe I wrote that 11 years ago!)
Still, I feel that most software architects really inflate the importance (and time) of their jobs. It's true that there is some amount of legitimate research to be done in exploring the broad outlines of your solution. However, most of the time those solutions are dreamed up by the architect in a few hours and then they spend months doing confirmatory biased research to flesh out the justifications for their original idea. That's the waste. As the plover said, all that knowledge about design patterns, etc. is still applicable. Just don't do it in a big up-front fashion.
Two articles that I wrote about this:
The Software Construction Analogy is Broken
and
Technical Push-Back
I don't have a lot of patience with the profession since it's built on a fatally flawed analogy and all software architects ever do is waste and overhead from a lean perspective.
I'm not confused. I just assumed that people could make a small mental leap: Working software = (functionality + quality + ease of use) whereas comprehensive documentation = waste in order to accommodate for lake of ease of use or poor quality. I hoped that the functionality and quality part of working software would generally be understood without me needing to be pedantic.
I'm guessing that there aren't a lot of people on Slashdot who are both users and developers for Odoo / OpenERP. I am. I am also formerly a UX expert (late 90's, but I keep somewhat up-to-date), and I am currently an active developer and consultant. I have some very specific views on this based on my background.
1. In the Agile manifesto it says "Working software [is valued] over comprehensive documentation." That has always meant, to me, that UX takes priority over user documentation. I've seen Agile teams kick the snot out of competitors by focusing on UX and foregoing nearly all user documentation. When I say "nearly", I mean that a very high level (well written) orientation document, is sufficient.
2. For this system itself which is a complex ERP system, there are four levels of "documentation" possible: a) User Documentation b) Configuration Documentation c) Customization / Plug-in Developer's Documentation and d) Internal Development Documentation. Since Odoo is open-source, in a way, all of these levels are "user documentation".
3. UX absolutely needs to be the one and only factor in considering the end user experience of an already-configured system. There shouldn't be any need for an end user to go to a user manual unless an organization has done extensive configuration / customization (in which case that organization has the responsibility for the documentation, not the Odoo organization. Likewise, UX should be the main approach to making configuration easy, but there may be some scenario-based examples documented to help orient those who are doing the configuration. These are your day-to-day admin users. The marketing automation module is a good example of where UX sucks and the documentation is poor. Given the choice, I would much prefer the UX to be improved!
4. For customization and internal development, there is still a role for UX to play, but (knowing the actual state of the documentation) you must improve that documentation dramatically. It is sparse and hard to follow, hard to find the right information, and often has very old / outdated screenshots. Although what information there is seems to be accurate, there are often huge gaps, and many undocumented api's and options. I know this because I have had to struggle through creating custom modules by reading through reams of source code in other modules. Love that it's open source, hate the quality of the developer documentation :-)
As a sideways promotional plug, our Scrum Team Assessment tool is built on OpenERP 7.0.
Lastly, Dr. Amit Goswami, Ph.D., theoretical nuclear physicist
And a theoretical nuclear physicist is more qualified than biologists like Coyle and Dawkins to write about evolution because... ?
That's a veiled ad hominum argument - a logical fallacy. Just like you have asserted that someone should read Coyle and Dawkins, you in turn might consider setting an example by examining the arguments of Dr. Goswami.
FWIW, I haven't read any of these references, but I have read extensively on all sides of the argument including evolutionary biologists, intelligent design proponents and other non-standard models for what we observe. I've read other Dawkins books and found them to be just as weak as many of the ID books. As far as I can tell, it's all still philosophy, and the science that we have, namely molecular biology, breeding and the fossil record do not show evolution as the conclusive final word on how life works.
I have no idea if this would help, but with developments in solar technology, would it make a significant difference if the tops of the wings, fuselage, tail and fan ducts were all solar panels? Seems like a simple thing to do to help with range... maybe not done because it's not reliable.
I've been faced with this kind of decision a number of times. I always remember: if I'm not filthy stinking rich right now, then I'm probably bad at predicting the future. Any attempt to do so should be taken with a huge dose of scepticism.
That said, I think that the practical answer is simple: invest a bit of time doing a bake-off of the likely candidates. Try to choose some real high-priority business features, and then get very small teams of 2 or 3 people each to use each of the frameworks to build production-quality functionality for those business features. Don't take more than a week to do this. To use your example, Flex vs. HTML5, you would get two small teams to try to build the _same_ functionality using the two different frameworks.
Evaluate your results based on how much the teams actually got done. (Remember: production quality, not prototype quality.)
Since you can't predict the future, I also strongly recommend good Agile Engineering Practices to help to build a system that is not just change-tolerant, but is actually easy to change.