Newton on Tact

From Sutter's Mill:

Tact is the knack of making a point without making an enemy.

How to create "interesting, cool, and relevant software"

From raganwald:

The only workable system for generating interesting, cool, and relevant software is well-known. Find a bunch of really smart programmers and point them at a large problem space for which there are actual users, and for which new solutions are unconstrained by old designs.

—Mencius Moldbug, What's Wrong with CS Research

Note the desired outcome: Interesting, cool, and relevant software. Do not become mired in empty debate over the phrase "smart programmers." Instead, ponder the other three preconditions: a large problem space, actual users and most especially no constraints by old designs.

Alan Kay is purported to have said, "A fresh perspective is worth 80 IQ points." You cannot have a fresh perspective when you are encumbered by backwards compatibility.

Meta-level thinking

From Ola Bini:

I have been trying to figure out what characterizes some of the best programmers I know, or know about...

When people try to become better programmers there are generally a few different kinds of advices you can get. The ones that seem prevalent right now is (among others):

• Learn - and understand - Lisp
• More generally, learn a new language that is sufficiently different from your current knowledge
• Work with domain specific languages
• Understand metaprogramming
• Read up on the available data structures (Knuth anyone)?
• Implement a compiler and runtime system for a language

5 Rules for Making Money During a Recession

From The Huffington Post - Ann Handley:

• Don't cut the budget.
• Maintain strong launches.
• Get a little silly.
• Beware the slash and burn.
• You might as well dance.

Dates vs. Quality

From thisDev (Roy Leban):

What's the best way to avoid problems?

• Work at a small company (or in a small group) so you can set your own dates. Large organizations tend to be top down and impose schedules without any idea of what is actually happening.
• When you start out, set the date based on what you hope to accomplish. Or, set the date first, then pick a feature set you can implement in the time available. Or, iterate back and forth. But, whatever you do, don't set them independently of each other. I know this isn't news to anybody reading this blog, but it still seems to get ignored a lot.
• Be willing to cut anything -- anything -- if you have to make your date. Even features that are almost done. You can always ship them later. If you have an immovable force and an irresistible object, the dev team explodes.
• Be willing to change the date if you can't get the quality you want (my wife and I slipped our wedding date because we weren't going to have the quality we wanted on the original date we picked).
• Stay calm. No matter what, you will be dealing with the issue at the end.

They say, on the Internet, nobody knows you're a dog. Similarly, nobody has any idea what you were going to ship or (hopefully) when you were going to ship. They only know what you actually do ship. And, if you don't ship in the first place, it's pretty hard to ship updates.

The Ethics of Elfland

As much as I ever did, more than I ever did, I believe in Liberalism. But there was a rosy time of innocence when I believed in Liberals.

It is quite easy to see why a legend is treated, and ought to be treated, more respectfully than a book of history. The legend is generally made by a majority of the people in the village, who are sane. The book is generally written by the one man in the village who is mad.

-- G.K. Chesterton (Orthodoxy)

Five Years in Iraq - What's the Problem?

From The Huffington Post:

We know the numbers - 1 trillion dollars, 5 years, 775 detainees in Guantanamo, 935 false statements made by the administration, about 4,000 dead Americans, 30-50,000 wounded soldiers, over 100,000 soldiers with treated and untreated PTSD, almost a million dead Iraqis, 2 million internally displaced Iraqis and up to 3 million Iraqi refugees who have left the country.

But apparently this is not a problem...

...unlike the Jesus we remember this Easter, overcoming death to raise our own moral standards and free us from unproductive and selfish lives - the dead Americans and Iraqis are going to stay dead as permanent testaments to our lack of ethics, our economic barrenness, and our supreme selfishness. One thing is for sure - and maybe the mainstream media actually got it right. You can't blame Bush and Cheney, five years later.

-- Karen Kwiatkowski

12 Essential Rules to Live More Like a Zen Monk

From Zen Habits:

“We have more possibilities available in each moment than we realize.” - Thich Nhat Hanh

1. Do one thing at a time.
2. Do it slowly and deliberately.
3. Do it completely.
4. Do less.
5. Put space between things.
6. Develop rituals.
7. Designate time for certain things.
8. Devote time to sitting.
9. Smile and serve others.
10. Make cleaning and cooking become meditation.
11. Think about what is necessary.
12. Live simply.

White knights [?!]

From Crooked Timber:

Readers used to the natural order of things might be concerned by the implication that with such a giveaway price, the top brass at [Bear Stearns] might be forced to bear the financial consequences of events that were obviously beyond their control. Never fear. According to this Reuters report in the Guardian, while most employees up to junior executive levels will lose both their jobs and the shares they were encouraged to buy, with no “golden parachutes:

JPMorgan Chief Financial Officer Mike Cavanagh late Sunday said taking over Bear would generate about $6 billion in merger-related costs.

JPMorgan has not broken down those figures, but much of that will be earmarked for severance pay and potential exit packages for top executives like Schwartz.

A person familiar with the transaction told Reuters that roughly $1 billion of those costs would be earmarked for severance and retention.

Eternal Memory: Metropolitan Laurus

From ORA ET LABORA:

His Eminence, Metropolitan Laurus of Eastern America and New York, First Hierarch of the Russian Orthodox Church Outside Russia, has reposed in the Lord.

From what I have heard, he served the Liturgy of the Presanctified Gifts on Friday, then felt too ill to perform tonsures later that evening. He was found in his "skete" (his small cell a few hundred yards from the monastery) this morning, having reposed in his sleep.

The Lord chose to receive Vladyka Laurus on the Sunday of Orthodoxy...

Please pray for the soul of the newly-departed servant of God, Metropolitan Laurus.

May his memory be eternal!

Ban All Cars Getting Less Than 35 MPG?

In the midst of rethinking my own Jeep ownership (20/24 mpg US rating for the Liberty - but I doubt I get that much) I came across this commentary/opinion - via Autopia from Wired.com:

The former head of Royal Dutch Shell has gone way out on a limb and urged the European Union to ban all vehicles that get less than 35 mpg, saying it is the only way to significantly address global climate change and force the auto industry to build more efficient vehicles...

Sir Mark Moody-Stuart, who spent his career working for the giant oil company, says an outright ban is needed because so-called "gas-guzzler" taxes do not work - and aren't fair because they let those with the means to pay them skirt responsibility for reducing greenhouse gas emissions...

Moody-Stuart, who is currently chairman of the mining group Anglo American, says he is a great fan of the free market, "but like most things, they have a failing. Without regulation to channel their power, markets will not deliver things which are of no immediate benefit to the individual making his or her choice, even though they may be beneficial to society."

P.S. I just worked out my most recent gas mileage (US gallons): 12.3 mpg. (And that's with spending almost as much time on a tow truck hook as driving.) Groan.

Enough!

From RORATE CÆLI:

"At the end of this solemn Celebration, in which we have meditated upon the Passion of Christ, I wish to remember the late Archbishop of Mosul of the Chaldeans, Paulos Faraj Rahho, who died tragically a few days ago. His beautiful testimony of faithfulness to Christ, to the Church, and to his people, whom he had not wanted to leave, despite numerous threats, prompts me to raise a strong and heartfelt cry: enough with the bloodshed, enough with the violence, enough with the hatred in Iraq!

Benedict XVI - Angelus (March 16, 2008)

Eliza Programmer Dead

From DevTopics:

Joseph Weizenbaum, who invented the famous "virtual psychiatrist" computer program Eliza, died from cancer on March 5 in Groben, Germany at age 85.

> How does that make you feel?

Weizenbaum was a pioneer in computer science and professor at the MIT Artificial Intelligence Lab, where he created Eliza in 1966.

> Tell me more…

Eliza was a simple question & answer program in the form of today's online chat software. Eliza parodied a Rogerian psycho-therapist, mostly by rephrasing the user/patient's statements as questions and posing them back to the patient. This eliminated the need for a large real-world database.

> I'm not sure I understand you fully.

Eliza foreshadowed the potential of artificial intelligence, but Weizenbaum was stunned to discover how many people became engrossed in conversations with Eliza, even revealing intimate personal details. Over time, Weizenbaum grew skeptical about technology's ability to improve the human condition.

> Can't you be more positive?

In his 1976 book, Computer Power and Human Reason: From Judgment to Calculation, Weizenbaum criticized systems that substituted automated decision-making for the human mind. He also believed there were "transcendent qualities in the human experience that could not be duplicated in interactions with machines" such as "the wordless glance that a father and mother share over the bed of their sleeping child." (source)

> What does that suggest to you?

As Theodore Piszak wrote, Weizenbaum's book was "Superb…The work of a man who is struggling with the utmost seriousness to save our humanity from the reductionist onslaught of one of the most prestigious, active, and richly funded technologies of our time."

Try Eliza online

More on Joseph Weizenbaum

How to Make the Time for Your Personal Goals

From Zen Habits:

“Obstacles are those frightful things you see when you take your eyes off your goal.” - Henry Ford

One of the biggest challenges in trying to accomplish any personal goal is that we tend to put them off until tomorrow, or next week, in favor of more pressing matters at work and home. Unfortunately, tomorrow never gets here.

If you want to accomplish a goal, you have to start on it today...

1. One goal at a time.
2. Make sure you really want it.
3. Make it your top priority.
4. Reduce your commitments.
5. Keep it simple.
6. Stay focused.
7. Block off time.
8. Make it your most important appointment.
9. Show that you’re serious.
10. Find your time wasters.
11. Make it a part of your daily or weekly routine.

10 ways to improve your code

A summary of Neil Ford's Software Development West 2008 "advanced code hygiene" presentation, 10 Ways to Improve Your Code, aimed originally at Java programmers, but with wisdom for coders of many [or any!] stripes. (Ford is a senior application architect and "meme wrangler" at ThoughtWorks, an IT consultant that specializes in development and delivery of software, and that is home to object-oriented development, refactoring and agile authority Martin Fowler.) From Reg Developer:

1. Write the tests before writing the code.
2. Use static analysis tools.
3. Practice "good citizenship" by paying attention to how well your objects interact with the outside world. "Never let them exist in an invalid state."
4. Avoid indulging in speculative software development. "The goal should be to build the simplest thing we need right now."
5. Simplify essential complexity and kill accidental complexity.
6. Challenge programming conventions, such as writing long, unreadable test names, and blindly following the JavaBean specification to the detriment of your code.
7. Embrace single level of abstraction principle (SLAP). From Kent Beck's book Smalltalk Best Practices and Patterns: every public method should be as short as possible, and should consist of steps, each one of which is a private method. "Don't make abstraction leaps in your code."
8. Leverage existing platforms with languages targeted at specific problems and applications.
9. Learn every nuance of the languages you're using.
10. Change your perspective and consider "antiobjects." An antiobject is a kind of object that appears to do the opposite of what we think it should do. The object metaphor sometimes impedes the solution "by making us try to create objects that are too inspired by the real world."

It's the libraries, stupid!

From Why Apple Will Dominate Next Gen Computing - ReadWriteWeb (by Alex Iskold):

Let's be clear. It is not the language, but the libraries that matter. Every time I hear developers talk about a new language and say it is by far the best one, I just shake my head. A new language is not going to be usable in today's world unless all of the libraries are in place. As the complexity of our software increases, so do demands on libraries. Microsoft learned it the hard way with years of set backs when it rolled out .Net. Had it simply embraced and optimized Java, it could have been years ahead instead.

Apple choose a different path. For the last decade Apple has been wowing the crowds and investors with its flawless and lightening quick execution. Every new Apple announcement, we keep thinking that they won't top it. But every time, Jobs and his crew pulls another trick out of the hat. Clearly, Apple is a well-oiled machine that has perfected the art of execution. But beyond that, Apple's secret sauce has been its software. While others have been inventing new languages and frameworks, Apple kept perfecting and building up its code.

Since the early days, Apple embraced a language called Objective-C - an object-oriented flavor of the popular procedural language. When Jobs returned to Apple, one of the early smart decisions was to ditch the old operating system in favor of Unix. This moved allowed Apple to instantly tap into serious programmers while retaining a beautiful and simple UI. When Java came along, Apple was unmoved, because it was just too slow. In general, over the years Apple has ignored new languages and just stuck with its platform. Smart, disciplined and mature...

Lessons Learned at 37 Signals

From Sean Ammirati's summary on ReadWriteWeb of a talk by Jason Fried of 37signals at SXSW 2008:

37signals is a software company headquartered in Chicago that started as a interactive design company and has since become one of the leading software companies for personal productivity software. Currently over one million people and businesses use their productivity applications... They also are responsible for creating and then open sourcing the popular web developer language [sic] Ruby on Rails. Jason Fried is the company's founder.

Lesson 1: Ignore The Great Unknown

"...often as entrepreneurs, we worry about the impact of our decisions rather than just making the right decision. ...this is crazy, because decisions made today don't have to last forever - we 'must optimize for today.'"

Lesson 2: Watch Out for Red Flags

Red flags are ... words or phrases that end up causing problems in communications. For example: need, can't, easy, only, fast.

Lesson 3: Be Successful and Make Money by Helping Other People be Successful and Make Money

...This has become part of [37signals'] philosophy, looking for opportunities in the marketplace to "spot chain reactions and be the catalyst" around helping others.

Lesson 4: Target Nonconsumers and Nonconsumption

...The idea [from Clayton Christensen of Harvard Business School] is that there exists an entire market of nonconsumers, or people who have a need but existing players aren't targeting these people. The advantage of targeting this segment is that you minimize the chance for competition from entrenched players.

Lesson 5: Question Your Work Regularly

• why are we doing this?
• what problem are we solving?
• is this actually useful?
• are we adding value?
• will this change behavior?
• is there an easier way?
• what's the opportunity cost?
• is it really worth it?

Lesson 6: Read your Product

"The biggest sin on the internet right now is bad copywriting ... paying too much attention to pixels and not enough attention to words."

Lesson 7: Err on the Side of Simple

...always "start with the easy way."

Lesson 8: Invest in What Doesn't Change

Lesson 9: Follow the Chefs

Jason called chefs the smartest business professionals. ...they are aware that you become famous and successful by giving knowledge away. For example, chefs have cooking shows and write cook books. Yet it doesn't stop their restaurants from being successful. In fact, he claimed they are probably more successful because of their sharing.

Lesson 10: Interruption is the Enemy of Productivity

Lesson 11: Road Maps Send You in the Wrong Direction

When talking about business plans, financial projections, or features for products 37signals believes road maps are bad, because "they lock you into the past." The only exception is APIs, because people are counting on it. ..."do the right thing at the right time."

Lesson 12: Be Clear in Crisis

At the beginning of this year, 37signals had some infrastructure problems that resulted in a few hours of unscheduled downtime. This was widely discussed on the internet. They quickly posted about what had happened and during the technical problems they kept their homepage updated with status messages. Through this experience, it reinforced their belief that people love you even more if you are open, honest, public and responsive during a crisis.

Lesson 13: Make Tiny Decisions

Rather than trying to make major decisions, when possible, Jason encouraged entrepreneurs to break problems down to the atomic level. In web properties, this is especially powerful because they've been able to break features down to the atomic level and then launch them one at a time. This is good because the team can gain momentum and celebrate little launches. However, it's also good because "when you make tiny decisions, you can't make big mistakes."

Lesson 14: Make it Matter

Jason ended his presentation by encouraging the audience to make sure their work was significant. He talked about how meaningful he felt the products they were creating were for individuals. ..."everything you do should matter."

Interface "Wow" Factor

From Code Commit:

That’s what it really all comes down to: user perception.  Jeff Atwood harps on about this constantly, but just because it’s oft-repeated doesn’t make it less true.  It doesn’t matter what your application can do, just what your users think it can do.  It’s all an elaborate illusion anyway, we just have to realize how complete that illusion really is.  If a user looks at your application and thinks, “Wow!  I don’t know what it is, but it looks powerful,” then you have succeeded as a developer.  Your application could do nothing more than print “Hello, World!” an infinite number of times; so long as it is impressive looking, it will be a success (think iPhoto 1.0).  Likewise, your application may desalinate water and hold the key to world peace, but if it looks wimpy, users will never give it a chance.

How to Find Good Ideas for Business and Life

Excellent article by Donald Latumahina from Life Optimizer:

There is a lesson ... I learned from the book On Writing Well:

You should always collect more material than you will use. Every article is strong in proportion to the surplus of details from which you can choose the few that will serve you best.

...to find good ideas, you should:

• Have as many ideas as possible, and then
• Choose the few ideas that serve you best

...here are some steps to find good ideas:

1. Expect ideas from every situation
2. Bring a capture tool wherever you go
3. Don’t filter the ideas you get
4. After you’ve collected enough ideas, filter them

. . .

Besides collecting as many ideas as possible, it’s good to increase the quality of your input. That way you can have higher-quality ideas to choose from. Here are some tips to increase the quality of input:

1. Diversify your reading
2. Choose the most important book to read next
3. Get the most out of your reading
4. Surround yourself with positive people
5. Find a mentor
6. Use the art of arbitrage and increase your arbitrage power

Software Engineering Goals

From 72 Miles Software:

• Modifiability
• Understandability
• Reliability
• Efficiency

Babies See Pure Color...

From Wired Science:

Babies See Pure Color, but Adults Peer Through Prism of Language

When infant eyes absorb a world of virgin visions, colors are processed purely, in a pre-linguistic parts of the brain. As adults, colors are processed in the brain's language centers, refracted by the concepts we have for them.

How does that switch take place? And does it affect our subjective experience of color? Such tantalizing questions, their answers still unknown, are raised by this developmental shift in color categorization, described today in the Proceedings of the National Academy of Sciences...

Application Development in the "Cloud"

From an article on GigaOM written by Geva Perry (chief marketing officer at GigaSpace Technologies):

...Although it is difficult to come up with a precise and comprehensive definition of cloud computing, at the heart of it is the idea that applications run somewhere on the “cloud” (whether an internal corporate network or the public Internet) – we don’t know or care where. But as end users, that’s not big news: We’ve been using web applications for years without any concern as to where the applications actually run.

The big news is for application developers and IT operations. Done right, cloud computing allows them to develop, deploy and run applications that can easily grow capacity (scalability), work fast (performance), and never — or at least rarely — fail (reliability), all without any concern as to the nature and location of the underlying infrastructure.

Taken to the next step, this implies that cloud computing infrastructures, and specifically their middleware and application platforms, should ideally have these characteristics:

• Self-healing: In case of failure, there will be a hot backup instance of the application ready to take over without disruption (known as failover)...
• SLA-driven: The system is dynamically managed by service-level agreements that define policies such as how quickly responses to requests need to be delivered...
• Multi-tenancy: The system is built in a way that allows several customers to share infrastructure, without the customers being aware of it and without compromising the privacy and security of each customer’s data.
• Service-oriented: The system allows composing applications out of discrete services that are loosely coupled (independent of each other)...
• Linearly Scalable: Perhaps the biggest challenge. The system will be predictable and efficient in growing the application. If one server can process 1,000 transactions per second, two servers should be able to process 2,000 transactions per second, and so forth.
• Data, Data, Data: The key to many of these aspects is management of the data: its distribution, partitioning, security and synchronization...

What Stanford Learned Building Facebook Apps

Some of this may be specific to Facebook "apps" ... but, then again, many of these points can easily be applied to "traditional" application development as well. (And should be.) From ReadWriteWeb:

Dr. BJ Fogg and Dave McClure taught a class last semester at Stanford on Building Facebook Applications. In 10 weeks, the 80 students had created 50+ applications and in total had over 20 Million installs - with 5 having more than 1 million users.

At today's Graphing Social Patterns conference, BJ and his two teacher assistants shared 10 tips they learned from the experience. Here they are:

1. It's never too late to create a winning app
2. Simplicity & clarity are key to app success
3. Aim for speed & flexibility in launch and iterations
4. Community cooperation leads to success (in other words, the most successful students shared the most)
5. Individual opinion about apps are worthless, you need to get out there and see what happens
6. Copying success is a cheap / fast way to succeed
7. Metrics do matter, but today's tools are too weak
8. You CAN learn to create a winning app
9. Success comes from the CHAOS / CONTROL Cycle
10. Mass Interpersonal Persuasion is finally here

Google's Engineering Philosophy

From Google Operating System:

12 principles that guide programming at Google:

1. All developers work out of a ~single source depot; shared infrastructure!
2. A developer can fix bugs anywhere in the source tree.
3. Building a product takes 3 commands ("get, config, make")
4. Uniform coding style guidelines across company
5. Code reviews mandatory for all checkins
6. Pervasive unit testing, written by developers
7. Unit tests run continuously, email sent on failure
8. Powerful tools, shared company-wide
9. Rapid project cycles; developers change projects often; 20% time
10. Peer-driven review process; flat management structure
11. Transparency into projects, code, process, ideas, etc.
12. Dozens of offices around world => hire best people regardless of location

The March of Progress

Funny but sad, too - especially if one happened to be programming in those intermediate years. From Cay Horstmann:

1980: C 
	printf("%10.2f", x);
1988: C++
	cout << setw(10) << setprecision(2) << showpoint << x;
1996: Java
	java.text.NumberFormat formatter = java.text.NumberFormat.getNumberInstance(); 
	formatter.setMinimumFractionDigits(2); 
	formatter.setMaximumFractionDigits(2); 
	String s = formatter.format(x); 
	for (int i = s.length(); i < 10; i++) {
		System.out.print(' '); 
		System.out.print(s);
	}
2004: Java
	System.out.printf("%10.2f", x);

Why Programming Languages?

I like this. From : So Jake Says: "People are the Problem, not Operator Overloading":

...we first need to look at the reasons that programming languages exist.

• So that people can efficiently talk to the computer.
• So that people can read how other people talk to the computer.

That’s it. There are no more reasons.

How to Start a Start-up

You need three things to create a successful startup:

• to start with good people,
• to make something customers actually want,
• and to spend as little money as possible.

Most startups that fail do it because they fail at one of these. A startup that does all three will probably succeed.

-- Paul Graham

Night Reader

About 3-2-1 Launch by Hashrocket

Hmm. A lot to think about in this post about the development philosophy and methodology of Obie Fernandez' new company Hashrocket. And to learn from. And, if possible, to apply personally.

...my new startup company named Hashrocket. (We are named after the ubiquitous key/value => operator in Ruby.) One of our two principal offerings is called 3-2-1 Launch...

We ... came to the conclusion that a span of 3 days is just enough time to get a new project off the ground - enough to nail down some distinguishing functionality, without sacrificing quality and good looks. Of course, it's not applicable to all projects -- our team of developers is 4-6 people (mostly working in pairs) which limits the amount of complexity we can tackle in one 3-day iteration (which we've taken to calling "orbits").

Here's a quick list of factors that empower us be ultra-productive in 3 days:

• Expertise in Ruby, Rails and BDD (using RSpec)
• Heavy automation of common tasks (pretty much anything repeatable is automated, including our initial application bootstrap which includes basic functionality such as authentication)
• Smart use of web services such as Amazon's EC2 and S3
• Reliance on Rails-based web 2.0 tools such as Basecamp, Highrise, Lighthouse, and Beanstalk

The 3 scheduled days (always Mon-Wed) refers strictly to implementation work, specifically the first iteration, ending with a public release of the software. Prior to the 3 days, our contract specifies a time period of 3 weeks during which we agree on detailed specification ... and high-fidelity mockups. What we're looking to achieve is a high level of confidence that we'll be able to launch in 3 days, and that necessarily involves locking down requirements prior to implementation. We've talked about an abort mechanism if anybody on the team thinks we're not going to achieve a successful launch (unveiling) on Thursday. If an abort were to occur, we'd postpone the launch for the next available date (probably the following week) at no additional charge to the client.