Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
Presentation
Recorded at:
Shaw and Fowler About Forging a New Alliance
Presented by Scott Shaw and Martin Fowler on Oct 06, 2008 01:35 AM
Summary
Scott Shaw, Director of Services at ThoughtWorks, and Martin Fowler, Chief Scientist at ThoughtWorks, talk about the need for a new relationship between the business department and the IT department. Studies have constantly shown that the main culprit for unsuccessful projects lies in miscommunication between the business people and the IT ones.
Bio
Scott Shaw is a manager and technologist with over 15 years experience building large-scale, distributed software systems for a variety of business domains. Martin Fowler is one of our industry's most well known thought leaders having had an influence in the adoption of OO, refactoring, patterns, agile methodologies, domain modeling, UML, and XP.
About the conference
ThoughtWorks recently began hosting events for Business and IT Leaders as well as technology practitioners to share insight and best practice across the industry. The briefings and the Exec Breakfast series are all grounded in reality - speakers are active practitioners, passionate about their work. The events focus on technology in relation to business issues, rather than being deeply technical.
Scott Shaw, Director of Services at ThoughtWorks, and Martin Fowler, Chief Scientist at ThoughtWorks, talk about the need for a new relationship between the business department and the IT department. Studies have constantly shown that the main culprit for unsuccessful projects lies in miscommunication between the business people and the IT ones.
Bio
Scott Shaw is a manager and technologist with over 15 years experience building large-scale, distributed software systems for a variety of business domains. Martin Fowler is one of our industry's most well known thought leaders having had an influence in the adoption of OO, refactoring, patterns, agile methodologies, domain modeling, UML, and XP.
About the conference
ThoughtWorks recently began hosting events for Business and IT Leaders as well as technology practitioners to share insight and best practice across the industry. The briefings and the Exec Breakfast series are all grounded in reality - speakers are active practitioners, passionate about their work. The events focus on technology in relation to business issues, rather than being deeply technical.
RelatedVendorContent
Agile Development: A Manager's Roadmap for Success
Achieving Results with Red Hat Integrated Virtualization
Related Sponsor
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
lean, war for talent and IT organisations
by
Gerald Loeffler
Posted
Oct 7, 2008 6:00 AM
Re: lean, war for talent and IT organisations
by
Christopher Churchill
Posted
Oct 8, 2008 7:17 AM
Re: lean, war for talent and IT organisations
by
Mike Granger
Posted
May 26, 2009 1:51 AM
To Infoq
by
Christopher Churchill
Posted
Oct 8, 2008 7:22 AM
Re: To Infoq
by
Deborah Hartmann
Posted
Oct 14, 2008 7:25 AM
Re: To Infoq
by
Christopher Churchill
Posted
Oct 15, 2008 9:47 AM
The same second post with proper formatting.
by
Christopher Churchill
Posted
Oct 8, 2008 7:26 AM
Lean Software Development Value Stream Map
by
Mike Bonar
Posted
Oct 8, 2008 9:42 AM
Re: Lean Software Development Value Stream Map
by
Christopher Churchill
Posted
Oct 9, 2008 1:43 AM
by 2020 - any made up number is as good as statistically proven?
by
Stan D
Posted
Oct 15, 2008 12:50 PM
-
let me pick on two aspects of this otherwise very good presentation:
the idea that the IT department should be abolished because IT and business suffer from a communication gap is needlessly naive. most workflows and value chains in organisations cut through several departments, and still these departments have a reason to exist, not the least because one must pick some meaningful way to structure a large group of people. finding efficient and effective ways for people to collaborate across departmental boundaries is a common challenge for management, and "project teams" are the typical answer. IT departments are not special: for the actual work in a software development project, it is largely irrelevant what department the team members originate from: the existence of IT departments need not stand in the way of excellent project execution.
on Lean and the war for talent: for 20 years we've been studying the Toyota way, Kaizen, Agile, Lean, whatever you may call it, and we've learned a lot. but the facts of renumeration in organisations fly in the face of this approach's core principle that it is the people "on the ground" doing the actual work that know best what to do and how to do it: moving up the organisational hierarchy is now financially rewarded more than ever. the renumeration gap between those that carry the workload and those that carry "responsibility" becomes wider by the day. and i expect that it is no different at Toyota.
cheers, gerald
http://www.gerald-loeffler.net -
Spot on! Furthermore, let us not forget that the Toyota model was never successfully applied to software, people claim to do it successfully well (We see organizations talk every day about lean and kaizen and a factory based process for developing software), I have yet to see a successful project that emphasizes a lot on lean and toyota and kaizen. :-(. The reason is every enterprise software, or software for any type of problem domain, is a new invention, no "process" or factory assembly line model can reasonably produce enterprise software. And we still have not reached the age where we can download modules off the web and integrate them with our application without a huge amount of research. Even then the modules fail in production, and well what do you know, since I did not write them, It is very very tough for me to debug and find out where the problem lies, whether it is in the module or the rest of the subsystems in my app. Due to this and a myriad other reasons, there are not much of "reusable components" for enterprise software at all. Of course we have frameworks which leverage a lot of the development, but apart from that, the core components of the domain model such as order management in a retail domain, there are no frameworks which can do it in a "plug and play" fashion, even for vendor frameworks such as ATG, Comergent, there is a lot of configuration, extension to etc etc and much much more complex than customizing mechanical parts in a toyota factory. Things like applying the toyota model to software were invented by people sitting at golf courses, without even interacting with the folks that were doing the heavy lifting at their desks. I think Agile is a excellent process that claims to embody the spirit of software development that, there is nothing ceremonial about building software, Humans have their limitations of expressing in code, what they involuntarily do every day, and also it is difficult to test the entire state space of even a medium software application. Errors will occur in production, Compare this with a car produced at toyota :-). There should not be any errors in the ECU at all, and all cars adhere to this, the reason being: 1. the lifetime of an ECU is approximately 15 years, even though the brands of cars that the ECU may be installed in might differ 2. The functionality of an ECU is relatively small when compared to an enterprise application. Hence developers have the time to test the ECU extensively, before launch and make sure that is atleast 7 sigma compliant. Now, we can see how the Toyota model can only be applied to building cars and not building enterprise software. We are now going back to dynamic languages and DSLs most of which have support for minimal static analysis, which will further put us back with regards to testing the entire state space of an application. Probably we need something like a Java ++++ in static analysis atleast, if not statically typed, to bring us closer to production ready code, faster and quicker. The reason for the war for talent is to be frank, intelligent folks get turned off by venturing into the software world. Reasons being: 1. Some organisations emphasize Agile and Lean and develop complex enterprise apps with tight deadlines and very tough customers that frown when they see even a single error in production. Due to this, employees are forced to sit the whole day and night to test rigorously and develop with all the 'ilities' and then at the end of the day, they are paid pittance. This is happening in many organizations, some of which we assume to be awesome in tecnology. 2. I think the higher management in IT organizations need to stop calling the developers and architects as "resources". This sounds very "factory like" and is very de-motivating. Organizations will have to take a major step to prevent calling lower level heavy lifters as "resources". Call them "Consultants". Makes more sense too. 3. Most IT organizations contain an upper management of "blood suckers". If there was a way for employees to sit 24 hours a day for 7 days for the full year and pay them 10$ / hr, and the outcome of that would not result in the employee's death or any health hazards, these blood suckers will first push the button for that. They don't understand that apart from making money, there are certain responsibilites and values that they should have. Ironically, most of these companies have their slogan as "Respect for Human Values" or some shit like that, what a load of shit a$$. I did not believe when my friend, an MIT grad on CS, decided to move to catering and became a chef. When I asked him why not IT dude, come on, people out there need you, this was his reply " 1. Work life balance. 2. High Job Satisfaction 3. No Recession (Duh. For food ??) 4. Excellent Renumeration (some chefs in star hotels earn 105000$/annum (without the 24 hours work, work on weekends etc.) I could go on and on, but lets stop it here, all of us on Infoq know why people don't join IT, because ... ahem.. because of first hand experience ;-).
-
Infoq,
Could you maintain the carriage returns when you add the posts to your persistent store? My carriage returns gets lost and see how ugly the above post looks like. I know there are some tricks to maintain the carriage returns, but how am I supposed to know that the first time I ever type something on Infoq? Please add the functionality to maintain and reproduce the carriage returns for the posts.
Thanks. -
Spot on!
Furthermore, let us not forget that the Toyota model was never successfully applied to software, people claim to do it successfully well (We see organizations talk every day about lean and kaizen and a factory based process for developing software), I have yet to see a successful project that emphasizes a lot on lean and toyota and kaizen. :-(. The reason is every enterprise software, or software for any type of problem domain, is a new invention, no "process" or factory assembly line model can reasonably produce enterprise software. And we still have not reached the age where we can download modules off the web and integrate them with our application without a huge amount of research. Even then the modules fail in production, and well what do you know, since I did not write them, It is very very tough for me to debug and find out where the problem lies, whether it is in the module or the rest of the subsystems in my app. Due to this and a myriad other reasons, there are not much of "reusable components" for enterprise software at all. Of course we have frameworks which leverage a lot of the development, but apart from that, the core components of the domain model such as order management in a retail domain, there are no frameworks which can do it in a "plug and play" fashion, even for vendor frameworks such as ATG, Comergent, there is a lot of configuration, extension to etc etc and much much more complex than customizing mechanical parts in a toyota factory. Things like applying the toyota model to software were invented by people sitting at golf courses, without even interacting with the folks that were doing the heavy lifting at their desks.
I think Agile is a excellent process that claims to embody the spirit of software development that, there is nothing ceremonial about building software, Humans have their limitations of expressing in code, what they involuntarily do every day, and also it is difficult to test the entire state space of even a medium software application. Errors will occur in production, Compare this with a car produced at toyota :-). There should not be any errors in the ECU at all, and all cars adhere to this, the reason being:
1. the lifetime of an ECU is approximately 15 years, even though the brands of cars that the ECU may be installed in might differ
2. The functionality of an ECU is relatively small when compared to an enterprise application.
Hence developers have the time to test the ECU extensively, before launch and make sure that is atleast 7 sigma compliant.
Now, we can see how the Toyota model can only be applied to building cars and not building enterprise software. We are now going back to dynamic languages and DSLs most of which have support for minimal static analysis, which will further put us back with regards to testing the entire state space of an application. Probably we need something like a Java ++++ in static analysis atleast, if not statically typed, to bring us closer to production ready code, faster and quicker.
The reason for the war for talent is to be frank, intelligent folks get turned off by venturing into the software world. Reasons being:
1. Some organisations emphasize Agile and Lean and develop complex enterprise apps with tight deadlines and very tough customers that frown when they see even a single error in production. Due to this, employees are forced to sit the whole day and night to test rigorously and develop with all the 'ilities' and then at the end of the day, they are paid pittance. This is happening in many organizations, some of which we assume to be awesome in tecnology.
2. I think the higher management in IT organizations need to stop calling the developers and architects as "resources". This sounds very "factory like" and is very de-motivating. Organizations will have to take a major step to prevent calling lower level heavy lifters as "resources". Call them "Consultants". Makes more sense too.
3. Most IT organizations contain an upper management of "blood suckers". If there was a way for employees to sit 24 hours a day for 7 days for the full year and pay them 10$ / hr, and the outcome of that would not result in the employee's death or any health hazards, these blood suckers will first push the button for that. They don't understand that apart from making money, there are certain responsibilites and values that they should have. Ironically, most of these companies have their slogan as "Respect for Human Values" or some shit like that, what a load of shit a$$.
I did not believe when my friend, an MIT grad on CS, decided to move to catering and became a chef. When I asked him why not IT dude, come on, people out there need you, this was his reply " 1. Work life balance. 2. High Job Satisfaction 3. No Recession (Duh. For food ??) 4. Excellent Renumeration (some chefs in star hotels earn 105000$/annum (without the 24 hours work, work on weekends etc.)
I could go on and on, but lets stop it here, all of us on Infoq know why people don't join IT, because ... ahem.. because of first hand experience ;-). -
Lean can certainly be applied to software development. Here's value stream map that I created to demonstrate the method: http://mikebonar.blogspot.com/2008/01/last-year-i-created-what-i-call-lean.html Note the starburst indicating business users perform functional testing.
-
Lean can certainly be applied to software development, for that reason, even the Toyota model can be applied to software development. Whether you produce successful software out of it, still remains to be seen. I have seen atleast 150 projects out of which 34 were done by Fortune 500s (not exaggerating), out of which 44 were lean, out of the 44, only 6 delivered value to the customer, and all of these 6 projects were paying high renumeration to the developers. Lean does not mean that your developers are motivated (if the salary is low). And no motivation for developers, means that there is something inherently bad in store for the project. Most organizations pay pittance to the software developers with low salary and expect to work on lean, which is not advisable. If you want models like lean to work, renumeration has to remarkably high.
-
Thanks, Christopher, and sorry for the ugly result. It's a known issue, but I've passed along your comment as well.
Note that an html < br > tag does work. Agreed, though: it's annoying.
deb -
I dont think it should be that much of a big deal anyways to add it. Sites like javaranch has it. :-).
-
It is a bit funny that number 2020 is used. I guess there is some plan behind that? Any links to the vision realization plan or pointers to the New Alliance? I'm a great believer in this vision, but in my opinion it requires attitude/processes/education revolution to happen soon to achieve the vision by 2020. My response here: http://plainoldstan.blogspot.com/2008/10/software-house-vs-in-house-development.html
-
I totally agree, the IT departement is really important. It can't be seen as an obstacle to communication, but more as a way to make the other departments work together. I really liked the video and i think it brings great ideas, but i do have to agree with the last comment. Mike Granger http://www.chickenrecipes.net
10 comments
Watch Thread Reply