Monday, March 5

Yi-Tan : Software Development Challenges

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: