User:Gregorio: Difference between revisions
No edit summary |
|||
Line 4: | Line 4: | ||
Its time to write a new page in the odyssey of my thinking on development. See my original idea below. I was in the trenches with that approach for about 8 months and it was a great experience. I also spent some cycles in those months thinking about learning and how the mind works. Time permitting I will start adding my latest ideas here. |
Its time to write a new page in the odyssey of my thinking on development. See my original idea below. I was in the trenches with that approach for about 8 months and it was a great experience. I also spent some cycles in those months thinking about learning and how the mind works. Time permitting I will start adding my latest ideas here. |
||
== The Highest Level == |
|||
Thanks, |
|||
Starting with the fundamental concept, you can break software development in to two parts: |
|||
1 - Decide what you want the software to do <br> |
|||
Greg S |
|||
This includes the interface, the data manipulation, the I/O, performance and target hardware. More importantly it includes and idea of what the user wants to get out of it. Unless you are developing programs to see what programming is all about (a good thing but a special case), you want to get something from the software. Maybe its to have fun, learn math, find information, answer a question, make money, make more software or something else. The user wants to do something and the program should be designed to help them accomplish that. |
|||
2 - Order the bits to achieve the users goal <br> |
|||
This is hard. Nonetheless, it comes after the first part and how you order the bits determines how successful you will be in achieving the users goal. |
|||
Both parts interact and inform each other. Often the user doesn't really know what they want the software to do until they see some software and get an idea of what it can do. One way to think about it is in terms of I/O. That is, you can see anything you want on the screen. What do you want to see? |
|||
Here's a trivial example exchange: <br> |
|||
User: I want to see a fractal. <br> |
|||
Developer: No problem, what kind of fractal? <br> |
|||
User: What choices are there? <br> |
|||
Developer: How about a Mandelbrot set?<br> |
|||
User: OK. <br> |
|||
Developer: Here's a program that generates a Mandelbrot set <br> |
|||
User: That's cool, can I zoom in on it? Can I look at some more fractals?<br> |
|||
Developer: OK, here's a program that can zoom in and out (you didn't ask for zoom out but I added it anyway). Here's a config interface that let's you define the series of any fractal you want to build. It includes a link to common fractals, their defining series and how to make your own series.<br> |
|||
User: Great, that's just want I want. Can you make it run a lot faster?<br> |
|||
Developer: Buy a better computer, I have work to do ;-)<br> |
|||
That's trivial because the output is a well defined mathematical construct, easily programmed and understood. Still, it takes some back and forth to get it right. The user really wanted to enjoy the visual excitement of fractals, poke around in them and understand how they get generated. The user would have had to think about themselves and probably see a therapist (or product manager) before they could express the requirements in that way. |
|||
Think about that exchange again with the initial request: "I want a program that teaches me math"... |
|||
= A proposed model for developing software = |
= A proposed model for developing software = |
Revision as of 18:15, 23 January 2009
My resume: http://wiki.laptop.org/images/3/35/Bio_Greg_Smith-2009.doc
A new chapter
Its time to write a new page in the odyssey of my thinking on development. See my original idea below. I was in the trenches with that approach for about 8 months and it was a great experience. I also spent some cycles in those months thinking about learning and how the mind works. Time permitting I will start adding my latest ideas here.
The Highest Level
Starting with the fundamental concept, you can break software development in to two parts:
1 - Decide what you want the software to do
This includes the interface, the data manipulation, the I/O, performance and target hardware. More importantly it includes and idea of what the user wants to get out of it. Unless you are developing programs to see what programming is all about (a good thing but a special case), you want to get something from the software. Maybe its to have fun, learn math, find information, answer a question, make money, make more software or something else. The user wants to do something and the program should be designed to help them accomplish that.
2 - Order the bits to achieve the users goal
This is hard. Nonetheless, it comes after the first part and how you order the bits determines how successful you will be in achieving the users goal.
Both parts interact and inform each other. Often the user doesn't really know what they want the software to do until they see some software and get an idea of what it can do. One way to think about it is in terms of I/O. That is, you can see anything you want on the screen. What do you want to see?
Here's a trivial example exchange:
User: I want to see a fractal.
Developer: No problem, what kind of fractal?
User: What choices are there?
Developer: How about a Mandelbrot set?
User: OK.
Developer: Here's a program that generates a Mandelbrot set
User: That's cool, can I zoom in on it? Can I look at some more fractals?
Developer: OK, here's a program that can zoom in and out (you didn't ask for zoom out but I added it anyway). Here's a config interface that let's you define the series of any fractal you want to build. It includes a link to common fractals, their defining series and how to make your own series.
User: Great, that's just want I want. Can you make it run a lot faster?
Developer: Buy a better computer, I have work to do ;-)
That's trivial because the output is a well defined mathematical construct, easily programmed and understood. Still, it takes some back and forth to get it right. The user really wanted to enjoy the visual excitement of fractals, poke around in them and understand how they get generated. The user would have had to think about themselves and probably see a therapist (or product manager) before they could express the requirements in that way.
Think about that exchange again with the initial request: "I want a program that teaches me math"...
A proposed model for developing software
Below is a brief introduction of my vision for a revolutionary development process that informs and is informed by the educational model of One Laptop.
I plan to start collecting user feedback and examples of educator - developer interactions that led to new software being built and used on One Laptop. I want to find the examples of how educators and students learn to build the XO software that is relevant for them
I will post links of examples on my talk page.
I'm a believer in constructionism based on my own learning experience and that of my children. My personal philosophy of education is most influenced, by my three children, by my wife who works at Educational Development Center (EDC) training school systems in violence prevention and by Paolo Freire.
I want to contribute to the theory of constructionism, but my most immediate value would be in helping implement the praxis of a problem-posing methodology in relation to the development of the technology.
For the last 10 years I have been a product manager for Video, Streaming Media, Content Delivery Networks and Core Networking products. My primary role is to engage with customers and users to generate requirements and communicate those requirements with engineering.
I'm a technologist but my specialty is listening and engaging users to determine the priorities for development. As a product manager I influence the engineering community to build products which satisfy the users needs. The users learn what is possible and the developers learn what is valuable to the users. My role is to facilitate the discussion, refine the design, and determine the right priorities within the constraints of available resources. Its an iterative process of communication and collaboration.
That's my vision of the product manager role in commercial software development. However, commercial software is limited by the hierarchical nature of the corporations involved. The user - developer relationship is also restricted by the need to generate revenue. The more a customer will spend the higher priority we give their requests.
Open source development addresses those limits with a decentralized and non-hierarchical model. The decisions about what gets built are informed by the developers own experiences and by developers responding directly to input from users. Thus, open source has significant advantages for developing software and hardware for a constructionist educational system.
That said, any development model needs an optimal process for synchronizing the work with the users expectations. Developers don't fully understand user's daily activities and users don't fully understand the constraints of the development process. Even for open source, the challenge remains how best to achieve a problem-posing methodology of mutual education. Both sides need an efficient way to engage the praxis (action and reflection) of creating relevant applications. Transformation of the process from developers giving users features (banking method) to developers-users learning from each other (problem-posing method) needs attention that empowers all to participate.
That challenge is especially acute when there are large gaps of culture, age, economic status, language, and geography (urban - rural and north - south). Even as users learn to develop their own code, there's a need for all users to have a say in what gets prioritized and delivered.
I'm not suggesting that I know better how to implement the development process. Only that I'm ready to engage a design dialogue that uncovers the principles and models of thinking which allow the XO to optimize the goals of the education systems.
Those are my ideas and I want to hear what you need.