Jeannette Wing, CMU, Frontiers in Research and Education in Computing
Jeanette said that there has been a paradigm shift.
Not just about computing's metal tools (transistors and wires), but also our mental tools (abstraction and methods)
Is this really a new paradigm shift? Maybe for the National Science Foundation (NSF), certainly not for anyone that has been working with software the last ten years.
The limits of Moore's Law forces the NSF to focus on programming languages and abstractions.
Three drivers of computing research, Society, Science, Technology.
Encouraged research areas:
- Data Intensive Computing
- Cloud Computing
Cyber-Physical Systems (computational core that interacts with the physical world)
- Smart vehicles
- Smart Flyers
Network Science and Engineering
- Understand the complexity of large scale networks
Socially Intelligent Computing
- Humans are still much better at image recognition
Programs where the human is a port of the program.
IT and Sustainability (Energy, Environment, Climate)
Computer Science and Economics
Computer Science and Biology
Agile development: Overcoming a short-term focus in implementing best practices, Karthik Dinakar
In the project they concluded on the following good practices.
- Good version control
- Coding guidelines
- Build automation
- Unit testing framework
- Automatic sanity tests
- Accurate task estimations
- Effective pre-spring planning
- Solid design discussions
- Involve QA and Operations
- Effective post-sprint-reviews
They also thought that it is difficult to implement best practices under way.
They had many problems:
- Integration was not in the plan
- Sprint backlog changing all the time.
- Long sprint meetings
Management did not allow them to implement the changes that they needed and the reason was "It's Agile!"
All in all, their problems seemed to be the usual, they had no idea of what it meant to do Scrum in the first place. Don't people read books anymore?
Are systems Green? Panel with Steve Easterbrook et al
- A Google query has a Carbon footprint.
- We don't know what it is.
- It may actually be less than the energy it uses since it may permit the person posing the query to save a lot of energy.
- The term Green is just marketing bullshit.
- It is not measurable at all.
- Carbon Emissions are permanent.
- It won't go away even if we stop burning any carbon today.
- The goal of emissions are ZERO, anything else is not sustainable.
There is a book called Green IT for Dummies
- What can we as a computing industry do.
- Analyze the problem.
- Make a list of what we need and can do.
- Create a wiki.
If you are going to read an article for more than three minutes, YOU SHOULD PRINT IT OUT! Believe it or not, but check your facts.
Architecture in an Agile World, Panel with Steven Fraser et al
Randy Miller: We allow the customers to make changes, but we don't tell them what the cost will be. If we have no architecture the cost will be high. The people behind the agile manifesto were all good at architecture and that is why the importance of architecture was not emphasized in the manifest.
Bill Opdyke: Some people seem to see a difference between architects and agilists. But most people that are good don't have the this problem. Architects can learn from agilists that change is not that hard. Agilists can learn from architects that architecture matters. There is a middle ground.
Ethan Hadar: We need a stable vision of what the architecture should be while delivering solutions iteratively. Show me the architecture road map of your product, because it will be integrated with another program in nine months. Accountability and responsibility for the architecture is important.
Dennis Mancl: You need to plan architecture early, or you will have to do it later on and then it will be harder.
Audience: How does an architect work in an agile team?
Randy Miller: From an agile team, you're all part of the team. There are no distinctions. The architect is in the team to make sure that
The architecture in the system is the point in time in which you have to step back and think about how everything interacts.
Ethan Hadar: The architect is the person, who needs to interact with the testers and operations to explain how and why the system is the way it is.
Dennis Mancl: The architect is responsible to the stake holders and he is responsible to know the problem domain.
Irit Hadar: The architect's role is to take a step back and say when it is time to review the architecture.
Audience: The architecture is what you get, regardless of what you do.
An interesting discussion, that could not find a consensus to if there is a need for a single architect or not.
Agile Anthropology and Alexander's Architecture, Jenny Quillien, Dave West, Pam Rostal
Do we need to pay any interest of to Christopher Alexanders' new book The Nature of Order?
The software community has always taken interest in Alexanders' books, but we take interest in the wrong things. We have only understood some rules, we have not grasped the deeper part of it, because we don't understand the culture of architecture.
In a pattern language, we looked at patterns, but we dismissed the QWAN. We missed the holistic point-of-view. Everything is part of the system, people, organizations. He is writing about things that are multi-dimensional and multi-faceted, not things that are simple and exact.
The Nature of Order contains the same multi-faceted ideas and if we look at it with the same eyes, we will miss the point again.
Alexander looked at centers and centers affect other centers. And there is no right or wrong, there are only degrees.
In Alexanders' world there is only one system, the Universe. Everything is connected!
Writing Code for Other People, Tom Mullen
Chunking and Memory
- The mind groups memory into chunks. Most chunks are stored in long-term memory. Out conscious is in long-term memory.
Short-time memory can only hold about seven relations. Short-time memory is also short:) This gives us a time-limit when traversing code.
Meyers' open-closed principle is an echo of the mind's way to learn things.
If the code is a reflection of our brains, then most brains contain spaghetti.
Analogies is the mapping from one thing to another.
Our brains are not good a processing more than 4 chunks at the time. This implies that we should write methods with less than four lines. Classes with less than four methods, modules with less than four classes, and applications with less than four modules.
Just a few small corrections on the Writing Code for Other People blog. The paper and presentation state that software elements should be chunked in groups of four or fewer (not 7). There can be more than 4 lines in a method but they must be chunked together in groups of 4.
Both the presentation (including the script) and the paper can be found at http://www.chunkinganalogies.com
BTW the comment about spaghetti brains is your own corollary ;-)
Tom: Sorry about the mistake. I've corrected it. Thanks for an interesting talk.
If you haven't read the book The User Illusion, I can recommend it. It deals with some interesting consequences of our limited minds.
Post a Comment