Scott Rosenberg - why isn't software easy?Scope of the project: tell the story of six different projects. Is software as hard as it seems and why?
Complexity of the project was so difficult - almost impossible. Became a story of a project that was in trouble and incomplete - and that is the way it happened.
Jerry: spellbound
Why are projects so difficult to manage, why are budgets so overrun? He followed Chandler from 2003 to 2005/6. Just around the time of Web 2.0 happening. Chandler knew this was happening which caused them to change course. Also followed
Web 2.0 is proof of concepts - almost all in perpetual beta state. When it becomes "successful" - big one buys it up and then either improves it or destroys it (e.g. myspace technical challenges)
Broadest conclusion - be humble - there are huge swamps and trouble ahead. Know the history, know what has happened - the biggest pragmatic take-away - work incrementally. Get som ething running quickly, feedback loop with users, etcera. Grand plan is almost impossible thing to complete in software.
People seem to have the "principle of exception" - yes, that is true, but! - people tend to exempt themselves from the reality around.
Al Chang - talking about browsers - client software is a challenge. Very important to pick the "right model".
Scott: when you select a form (like a sonnet in poetry), you can make it happen. Free verse - you get lost.
Al - when you think as a screenplay, then all of the players have to play to the script. Novels are a challenge - because you can keep writing and it never has to end.
Xanadu project - ever receding nightmare.
Scott: Firefox project. Started in 1997-98, years to get started. Many people wrote them off. They finally took it in pieces and took big bites and stayed with it. Took them much, much longer. Question - why?
Jerry: YAGNI - you aren't going to need it. Premature optimization is the root of all evil.
Scott: axe sharpening - taking forever to get your tools, setting up the right environment, right infrastructure - can almost become a job in of themselves. Often becomes a prject in and of themselves. Do not spend all of the time focusing on cleaning - and just do.
Al: search engine - make it simple. Mind also has a hard time handling the scale issue.
Scott: Quantity changes quality - as you scale/grow - does not grow as predictably. The dynamics of systems and communities change the scale.
Jerry: what were the major issues in the Chandler project? Scott: major personality clashes and major "bets" on the project. For example, they chose to use python for the project - not unheard of, but definitely unorthodox. They believed the gain would be from the build versus the dearth of libraries. Today, it is helping much better.
Jerry: AI intelligence with common sense reasoning project - the project hopefully will bootstrap. Scott: the naysayers are right until you prove them wrong.
Jerry: Apollo computers - problems with timing. Scott: software tied to hardware. Software-only project - is infinitely malleable. But, in theory, you can keep changing the platform (hardware) if you want to take care of the platforms. Agile changes.
When you have a lot of users - then you have the concept of legacy and you do not want to break compatibility.
Bill Seitz: every architectural decisions made in the beginning ends up causing the challenge later. Scott: fear is valuable up to a point.
Al: when things are infinitely malleable, people tend to
All about constraint management, rather than getting a particular project done. Used the constraints to make decisions.
Had to leave the call early.
No comments:
Post a Comment