168 karma · joined December 28, 2013
It does not have to be pair-teams. It can be 3-teams that review each other's code. Crafting shared libraries also helps focus multiple developers around code, docs, calling semantics and help surface implicit performance expectations or penalties early.
I have been the hero developer cranking 10K lines of C per month. But divide and conquer where software development MATTERS isn't very wise. Methods make sense when dozens of jobs, thousands of lives or millions of dollars are at stake every week and month of a project.
We used to call virtuous redundancy "belt and suspenders."
But I never enjoyed speaking with people who watch TV. That's why I found the Ultrix and the Net in the 1980's back at Harvard. I live in DC and like cities for policed walkable streets (I don't drive), live jazz, museums, book clubs and small ethnic restaurant venues.
But our consumer Net has been been a waste of time just like roadside American life has always been.
This is like the film "China Town" with cable utilities filling in for water utilities. I know I'm an old man, but nothing has changed much despite our SFX propaganda fictions.
His distinguishing states from civilization here is also instructive. We can further analytically carve "civilization" into different histories - industrial, arts, literary, architecture, agriculture, etc. - that divide our timelines into different overlapping periods of sin waving ascent, descent, advance or retreat.
"Not with a bang, but a whimper." - T.S. Eliot.
Second, Kurzweil is a creepy promoter of "inevitability." He is a bright guy with good access to privileged programmatic research. But he is a provocative peddling Howard Stern styled futurist.
I prefer Bill Joy's rightfully highlighting our policy options and virtues of learned caution. There are many things people can do we police against for good reasons.
Theoretical and now even many applied sciences deliver more cautionary signals than go-go-go signals. Software folks should take that as good news. Solving problems makes problems go away. Nice architecture and good food are their own problems without creating new ones.
North Americans who buy homes move every 7 years on average. We have troubles building value in places where people stay over generations to enjoy it. Even educators are learning that "tickets out" is too abstract a target to motivate remote kids to study in schools. We inherited our little patches of planet and histories, but we should not normalize our current widespread displacements. Folks are migrating to specific places for different reasons we can examine on maps. Other folks in tons of places have troubles making a go of where they are for reasons we understand and cannot fix. [Edit: grammar]
Product Selection Engines (PSE's) were a different value proposition than product or brand promotion. They are fun to write for engineers because they correct purchase errors with IT good deeds like Consumer Reports but with user variables on priorities or constraints.
The Consumer Web threw out a great deal of baby with the .com era bathwater.
Nothing is more damaging to adults or children than lives in remote isolation with delusions of Swiss Family Robinson self-sufficiency on government road, school and mortgage subsidies. We must stop claiming any normalcy to that post-Eisenhower makeshift accounting fiction. Lives in remote isolation are one of the reasons business formation is so low in the United States. Shyness is never any value. Shy people are takers.
Let's eliminate some cases. I know some people work on entertainment software or short term content. Others work in departments "against management" for take home pay. I never care about those projects or those people working on them. My words do not apply there.
Interesting hardware is not virtual but involves complex supply chains. The same goes for productivity software interacting with the world already in motion. New training often costs more than new tools. DC folks making NASD broker registration reality are essential personnel in tight supply chain relationships. Any error on a Congressional Report can tumble decision makers into felonies or disrupt global commodity markets. Same goes for folks writing device drivers or porting libraries to new hardware. None of this is any app buried in app stores or Office Space TPS reports.
In such greenfield or release cycle projects the right team size and composition will get there first, avoid mistakes, clean up markets later cheapest or occupy profitable niches longest.
Software projects concern progress and reach and thus "pass the bus test." Nature is not kind to the shy. Individual problem are just problems. Anybody can consult from anywhere if they can make a living that way. Otherwise, nobody cares about homebodies. Never project socials problems or commute logistics as values or virtues. Skunkworks remains the model for focus and shared responsibility. Software is not the deliverable. Tools and answers are the deliverables.
I don't enjoy moving picture fictions, recorded edited entertainment or packaged food. I went to Harvard and live in DC getting everything live and in person 24/7. I do not drive any cars and live on parks and zoos taxpayer dollars keep safe and manicure.
I worked with Steve Crocker and Brad Cox, so I am no luddite. Last I knew Crocker was on the board of a local theater group and also prefers his life live in person.
Authentic pleasures are almost impossible to get in suburban "modern" life where priests called "Therapists" charge hourly for confession and charlatans called "Teachers" do the same for scriptural studies. Our doctors are the lowest performing in the developed world.
The peculiar imaginations of rusting commodities, factory fake foods and delusional fictions are meritorious goes with American accents and propaganda.
Outright unsubsidized failures that never deliver any product to customers are mostly functions of communicative challenges. The opacity of costing for simple speed/space or protocol adherence engineering decisions is easy to underestimate. Business actors will nod and agree to anything that sounds good and give wrong signals. Others wave hands frantically around every buzzword and easy windfall demanding features. Many purchase agents subject to hype have no idea what they are buying and fetishize wasted software LOE. Training is routinely shortchanged for industries with high turnover.
Accept failure and then low quality as the norm. Then seek team members, suppliers, channel partners and customers around new or rekindled software with needs to focus intensively for 2 months and then 24 months. Most enduring software requires stakeholders more than customers. Leave other endeavors up to researchers and understand what capital resources amplify or do not amplify.
Splashing colors, fonts and pictures around free text is not marketing. The prevalent transactional design SOP over the last few decades was A/B's on "pig lipstick" for customers often not capable of judging possibly good outcomes. We suffered (and sold) multiple delusions of "portals" and "destination sites" only imagining their own immersive relevance to customer gazes. Those who did better or avoided over investment were exceptionally wise.
We have years and decades to clean up the Web dump from inoperative airbrushing at most local or broad market service reaches. I don't know who teaches real decision support based information architecture for commercial markets. We have data now on what works and what does not with requisite methods and metrics. Someone might fill a gaping niche.
Close attention and years of reading are important to writing code worth writing. I read literature oriented around "skunkworks" sized teams and applied them at somewhat similar scales. The better literature is fantastic. But the literature presumes too much of readers and means little outside operative exposure to multiple successful applications. Folks seeking method for quick home runs are barking up the wrong trees from the beginning.
I fashioned a 90's Agile type methodology based on Release abstractions and project progress visibility.
There were always 3 Releases (MRTP - Multi-Release Technology Plan) for parking inbound feature requests from inbound stakeholders. Developers shared "minds eyes" on future releases.
Then we group scheduled integration deliverables (not activities) by Weeks. Rare deliverables were given longer extensions. Sharing a spreadsheet of weekly deliverables to the next release required enough analysis to share the schedule abstraction.
Going dark was impossible. Everyone documented short "So Far, More To Go, Defer It" lists with short rationales similar to version control commit comments. We could push schedule breaking "features" to future releases. Every Thursday was integration and retime boxing of the schedule. The dev notes were collated into report "Weeklies." In practice, more continuous integrations were daily to his weekly hard integration targets.
The methodology started with a workbook of about 15 product planning exercises from User "day in the life" to "operational cost estimate" spreadsheet formalisms.
In practice developers shared a subset of the planning formalism "intermediate representations." But all stakeholders (business too) were fully aware and SIGNED ON to every planning step skipped for schedule or cost necessities.
It was very ritual high visibility human applied "design by contract." We had a perfect execution record on early Linux tooling with teams from 2-15 (Product Planners, Information Architect, Soft Devs, System Architects) on about 125 high pressure engagements. Most was a mix of Java Servlet, SMTP and C telecoms projects. We had to write our protocol handlers back then on shifting sand.
I might write it up as "The Adrenaline Way." It doesn't easily apply to individual, exploratory or Kanban content "journey without a destination" project teams. But it applies well to products with inbound and outbound marketing teams involved.