Summary
Since my (personally) revolutionary experiences with (1) dynamic languages and (2) open spaces conferences, I have been trying to understand how these revolutions happen. This presentation from the TED conference has given me some insights.
Advertisement
Here's the presentation (the part I'm talking about starts at 10:25 if you're impatient, but the whole talk is only 18 minutes long). Note that you can also get TED talks as audio podcasts through iTunes, and I've found almost every one of them to be mind expanding, so I've been listening to all of them. (Aside: I hadn't heard of the conference until someone pointed out a talk, and over time I've become a fan. Now I've even thought of attending the conference, to meet like-minded people. This makes a strong argument for capturing and distributing conference talks; I'm pretty sure we've been increasing the size of the Java Posse Roundup by podcasting the discussions).
The part of Pollan's TED talk that haunts me is his experience working with the innovative organic farmer. They section off part of the farm, and let cows graze on it. They move the cows, and let it sit for 3 days, during which time the maggots in the cow poop get all big and juicy, but don't turn into flies. At which time they release a bunch of chickens into the section, who love maggots and go tearing through the cow poop, scattering it all over and eating the maggots before they become flies. At the same time, they are distributing high-nitrogen chicken poop all over the section. When this is done, the section is left for a few weeks (while the cows and chickens are off working other sections), and the most amazing grass grows in that section, sending roots down into the soil. Then animals are brought back to eat this grass, which causes the roots to die back (to match the length of the grass above the ground), aerating the soil and giving the various underground microbes sustenance. The result: tremendous output of beef, chicken and eggs, etc. per acre, while at the same time enriching the soil. With no pesticides or fertilizers.
What fascinates me about this is that it's the same old tools, applied differently. The farmer jokes about "being a grass farmer," but by seeing that everything hangs on growing the best grass that you can, I think he has cracked the code of farming.
It's the change in perspective that makes the difference. In the case of farming, rearranging things so that every species gets what it wants the most.
I've been asking myself why dynamic languages and open spaces work so well, not just because I'm amazed but more importantly because I want to understand how to discover that "essence" that allows you to turn something into the best possible thing it can be. Indeed, if you listen to this roundup session, you'll hear me trying to figure it out for the daily working experience of software development (I'd like to create a company/group/association of developers that self-organizes the way an open-spaces conference does, but I have no idea how to accomplish that).
This idea of "essence" is also at the core of Domain-Driven Design, where you first discover the true nature of the Domain Model, and then the rest of the design flows from that (however, I do think that sometimes there are overarching architectural issues that can supersede aspects of the domain model. Perhaps Eric would argue that these then become part of the domain model).
So in the spirit of "make it about growing the best grass you can, everything else will follow," here's what I think might be the essences of some revolutionary ideas:
Dynamic Languages: Creativity. Programmers want more than anything to create. Give them more power to create, and they will be more creative. On the other hand, teach them that programming is all about boundaries, and they will look for boundaries. Is it any wonder that programmers who only learn Java in college want to know what the rules are, and assume that if the language doesn't tell them what to do they are free to make stuff up?
Open Spaces: Discussion. People go to conferences because they hope to have interesting discussions. Make the conference all about discussion, and it will be the best experience possible.
Agile: Honest Communication. All the biggest problems in software development start when people feel they must prevaricate. Little fibs eventually grow into giant fables, and everyone gets drawn into the deceit. The essence of Agile/Lean/Scrum is making sure everyone involved knows what's what, all the time, so that people can focus on producing software instead of bigger and bigger lies.
Business: Working Together. You can certainly argue that forming a business is all about making money (like running a farm is about producing beef and eggs), but I think that maybe the "grass" of business is that we want to experience the synergy of working together. My thoughts on this subject are still very early but if the organizing principle is "how can we optimize the experience of working together?" then I think we'll see some very interesting results.
What other essential concepts are out there, which -- if we can see them and reorganize around them -- can completely change the experience of a thing?
> Dynamic Languages: Creativity > Programmers want more than anything to create. Give them > more power to create, and they will be more creative. On > the other hand, teach them that programming is all about > boundaries, and they will look for boundaries. Is it any > wonder that programmers who only learn Java in college > want to know what the rules are, and assume that if the > language doesn't tell them what to do they are free to > make stuff up?
I'm a little confused by this. Isn't 'making stuff up' a form of creativity? Maybe you can elaborate on the distinction that I assume you are making?
I'm coming around to believing that the only "overarching architectural issues" would be enterprise wide licensed solutions or solutions approved for highly regulated uses.
Otherwise the domain should guide the solution - its cheaper and sturdier to do that, I think.
For me, there's creativity for good and creativity for evil.
When we provide rules, we limit creative space to live within those rules; we tend to "stay inside the box." When we provide no rules, we have anarchy (sometimes good, most of the time most folks think that's bad [except anarchists I guess]). And I think that's the dichotomy that's being presented here.
Finding the right balance is critical to success. The thing I'm pondering as I head into yet another agile methodology is, how do you find the sweet spot for creativity vs. anarchy, and should the team self-organize on that or is that an external influencer or both?
> Is it any wonder that programmers who only learn Java > in college want to know what the rules are, and assume > that if the language doesn't tell them what to do they > are free to make stuff up?
I wanted to say that was an unfair claim but then I realized that not only did it not apply to me, it doesn't apply to anyone I know. So instead I'll ask, is it fair?
I think what you were going for was more along the lines of if the all the languages you know impose the same limitations on you (or the intersection of those sets is large) then you are in danger of mistaking language rules for larger programming rules.
But that's not a limitation of any one language or even set of languages. It's a limitation of all languages (to a lessor or greater extent).
But that was just an aside. The idea of grass farming is something I'm going to have to give a lot of thought to.
Most programmers or small programming companies (which should make up maybe 80% of all that happens in programming) are service providers. I mean, they don't own the land. They are paid by customers to either water the grass, or herd the chicken or cattle on land owned by the customer, but not to do the whole cycle. Therefore IMO the analogy cannot work. It would be the customer who needs to learn grass farming, and my experience tells me customers are very bad at this.
In order for such a model to work, a company would need to provide hosting services, business and management consultancy and development services all in one package. I don't know of any company doing this type of business.
I worked with some really skilled industrial designers some years ago. You'd be surprised how much geometry, physics and physiology they know, and how much domain knowledge they develop in order to do their job properly. They're creative because they know a lot about rules and limitations, and are thus able to come up with solutions that work. Good designers are considered to be highly creative. My experience tells me that they are highly creative _precisely because_ they know the rules and limitations very well, not because they don't know them or are taught to disregard them. Why would this be different with programmers?
> In order for such a model to work, a company would need to > provide hosting services, business and management > consultancy and development services all in one package. I > don't know of any company doing this type of business.
I'm not sure about all of that. The business would only need to provide the services it needs for itself. Why would it need to provide hosting and consultancy?
I think a lot of businesses would be a lot better off if they just did stuff for themselves. I see businesses lose control of their core business processes through 3rd party software and outsourcing all the time.
Your post made me realize that the grass farmer analogy seems to fit what I've been arguing for years. One of things I hear people say is "we're not a software company" because we don't sell software. The farmer isn't selling grass but his success depends on growing grass. I hope we are seeing the start of the end of the specious reasoning that all functions of a business that aren't (arbitrarily) labeled 'non-core' should be outsourced. I wish more people knew that outsourcing is what turned Valu-Jet into Air-Tran.
>My experience tells me that they are highly > creative _precisely because_ they know the rules and > limitations very well, not because they don't know them or > are taught to disregard them. Why would this be different > with programmers?
A French professor I had in college admonished me for my "creative" grammar. She said, "You must know the rules first before you know where you can break them. Great writers don't follow proper grammar often but they know where they can break the rules and still communicate ideas." I think this can be generalized to any discipline: software development, music, culinary art, painting, etc.
> Your post made me realize that the grass farmer analogy > seems to fit what I've been arguing for years. One of > things I hear people say is "we're not a software company" > because we don't sell software. The farmer isn't selling > grass but his success depends on growing grass. I hope we > are seeing the start of the end of the specious reasoning > that all functions of a business that aren't (arbitrarily) > labeled 'non-core' should be outsourced. I wish more > people knew that outsourcing is what turned Valu-Jet into > Air-Tran.
You're a little more optimistic than I am James. My experience is that the third-party vendor mentality is driven by the comfort level of the CIO with software development. My own CIO has a background in industrial relations and absolutely no technical background. Needless to say he wants nothing to do with software development. My previous employer had a VP IT (no CIO) and she had a background in customer service: no technical background. They were also a vendor driven shop.
Unless more people who enjoy development choose to move through the management ranks, I don't see an end to the third-party vendor mentality.
> You're a little more optimistic than I am James. My > experience is that the third-party vendor mentality is > driven by the comfort level of the CIO with software > development. My own CIO has a background in industrial > relations and absolutely no technical background. Needless > to say he wants nothing to do with software development. > My previous employer had a VP IT (no CIO) and she had a > background in customer service: no technical background. > They were also a vendor driven shop. > > Unless more people who enjoy development choose to move > through the management ranks, I don't see an end to the > third-party vendor mentality.
If you are feeling brave, here's a book you can recommend to your CIO.
He makes a very strong argument early in the book for not outsourcing or attempting to buy software for business processes. The distinction being that software for, say, word processing, isn't going to differentiate your business but things that you do as part of you business should be built by you. It's a nuanced argument and I can't do it justice here.
> I'm not sure about all of that. The business would only > need to provide the services it needs for itself. Why > would it need to provide hosting and consultancy? > > I think a lot of businesses would be a lot better off if > they just did stuff for themselves. I see businesses lose > control of their core business processes through 3rd party > software and outsourcing all the time. > > Your post made me realize that the grass farmer analogy > seems to fit what I've been arguing for years. One of > things I hear people say is "we're not a software company" > because we don't sell software. The farmer isn't selling > grass but his success depends on growing grass. I hope we > are seeing the start of the end of the specious reasoning > that all functions of a business that aren't (arbitrarily) > labeled 'non-core' should be outsourced. I wish more > people knew that outsourcing is what turned Valu-Jet into > Air-Tran.
What you say makes perfect sense. However, I doubt that software development and maintenance is a core process of many non-programming companies, other than NASA running astrophysics simulations or banks running financial simulations.
Still, in the world as it is today, most programmers work for companies which live off selling development services, not software products. I cannot see the grass farmer model working for those companies.
I think it would help to clarify the idea to try to build analogies between grass, cows, magots, cow dung, chicken dung, chicken, ground and so on and specific IT-related items. I tried, I cannot come up with anything satisfying.
"What you say makes perfect sense. However, I doubt that software development and maintenance is a core process of many non-programming companies, other than NASA running astrophysics simulations or banks running financial simulations."
I took what James said very differently. It seemed to me he was saying that a finance company, for example, should write their own software with respect to loans, financial packages, approvals, etc. These functions are core to a financial business and are a differentiator from competitors. I don't think he meant that the same finance company should write their own HR or accounting packages, which can be safely purchased from a vendor.
> "What you say makes perfect sense. However, I doubt that > software development and maintenance is a core process of > many non-programming companies, other than NASA running > astrophysics simulations or banks running financial > simulations." > > I took what James said very differently. It seemed to me > he was saying that a finance company, for example, should > write their own software with respect to loans, financial > packages, approvals, etc. These functions are core to a > financial business and are a differentiator from > competitors. I don't think he meant that the same finance > company should write their own HR or accounting packages, > which can be safely purchased from a vendor.
Exactly. That's also the argument that Tony Morgan makes in the book I reference above.
The company I work for right now has bought software for core functions. The results are not good. In fact, these packages put the entire business at risk. Some issues:
0. Cost. Our IT costs are skyrocketing almost solely because of software licensing. 1. No documentation or common understanding of what our core processes are. What the system does is our process. No one knows if what the system does is correct or not. We are often out of compliance with federal or state regulations because of this. 2. Poor support / expensive support. Even if the vendor starts out great, they often are bought out. We don't have any say on the matter. Trivial changes to the software cost more than the salaries of several full time developers. 3. Integration is a nightmare. Vendors don't see any benefit in working well with their competitors. 4. Our vendors are becoming out direct competitors. One vendor was bought by our larger direct competitor. Another decided to enter our space. I don't think I need to explain why this is problematic. 5. Vendor lock-in. It is extremely difficult and costly to address any of the above because of 1.
> What you say makes perfect sense. However, I doubt that > software development and maintenance is a core process of > many non-programming companies, other than NASA running > astrophysics simulations or banks running financial > simulations.
But you are just repeating what I am arguing against. Where is the proof that 'non-core' processes (which is poorly defined by itself) should not be handled by a business? Secondly, I'd like someone to explain how a company's business processes, written in machine executable form is not 'core' to that business.
> Still, in the world as it is today, most programmers work > for companies which live off selling development services, > not software products. I cannot see the grass farmer model > working for those companies.
I don't think it does. That most developers work for those companies is a symptom of the problem.
Let's take the analogy and flip it around. Let's say the farmer works the way that most companies do. He sits down and says "what does my farm sell? Cows and chickens." Next, he decides to 'optimize' his business by outsourcing things that are 'non-core'. He doesn't make money off of growing grass. That's not core. But he needs grass to feed the cows. So he hires someone to make sure the grass grows. That company comes in and throws down fertilizer. All they are there to do is grow grass. They don't know anything about cows or chickens. As a result, the farmer spends more and gets less. In a corporation, he would be rewarded with a bonus for this.
Flat View: This topic has 16 replies
on 2 pages
[
12
|
»
]
Previous Topic
