Check out Stimuluswatch.org
The site lists all proposed "shovel-ready" projects, where the Obama administration is planning to invest the stimulus money.
OKay...What's new??
It let's people (not just administrators, contractors..but just about anybody who cares) to rate these proposed projects.
Simple, yet effective. Citizens with their knowledge on the local environment, rate these projects on it's viability. Provide comments on it's priority, suggest improvements. In turn, this gives an 'on the ground' perspective to the policy makers sitting in the capitol hill.
A number of critical attributes of such 'collaborative governance' stand out, such as
- Brings in transparency to decision making process involving public spending
- Makes authorities accountable for decisions made
- Harnesses collective intelligence
- Inclusive approach in policy making brings in a positive energy
I wonder if we can extend similar web 2.0 features to bring more transparency in Corporate Governance. In the current economic environment, where the purse strings are tighter than ever, can we go for an inclusive approach in determining where to invest the money on? Can we use this approach in prioritizing projects we pick for execution?
Would like to know what you think...
Reflections on impact of Digital on Business, agility in software development, Leadership and Organizational behavior.
Monday, May 25, 2009
Sunday, May 17, 2009
97 things every software architect should know
While browsing through my daily dose of RSS feeds on Google reader, I came across this interesting website, which talks of "97 Things every software architect should Know". Here are my top three picks (not in any specific order) out of the list of 97 'things' :-
1. Simplicity before generality, use before reuse :- Couldn't have agreed more. Having been a developer myself, I have seen developers often resorting to speculative design, under the guise of re-usability
2. Seek value in requested capabilities :- With apt examples the author, describes, how the role of a technical architect should be to help sponsor understand what they need. Ties back well to the agile manifesto
3. Pattern Pathology :- At times we assume design patterns to be the solution to all complex business problems. We enforce certain design patterns in project without checking if there are any simpler/ better solution available. The Author describes this symptom as 'Pattern Pathology' and makes a Strong case against it
Recommended reading for all..would like to know what are your picks..
1. Simplicity before generality, use before reuse :- Couldn't have agreed more. Having been a developer myself, I have seen developers often resorting to speculative design, under the guise of re-usability
2. Seek value in requested capabilities :- With apt examples the author, describes, how the role of a technical architect should be to help sponsor understand what they need. Ties back well to the agile manifesto
3. Pattern Pathology :- At times we assume design patterns to be the solution to all complex business problems. We enforce certain design patterns in project without checking if there are any simpler/ better solution available. The Author describes this symptom as 'Pattern Pathology' and makes a Strong case against it
Recommended reading for all..would like to know what are your picks..
Subscribe to:
Posts (Atom)