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.