97 Things Every Software Architect Should Know - The Book [97 Things] : Near-Time.

James Shore: The Documentation Myth.

This is an interesting side effect of security issues arising out of perhaps indexing that actually works “too well”.

Nice story about the happenings behind the scenes leading to google chrome.

So as you can see, lean and agile are deeply intertwined in the software world. You can’t really talk about them being alternatives, if you are doing agile you are doing lean and vice-versa. Agile was always meant as a very broad concept, a core set of values and principles that was shared by processes that look superficially different. You don’t do agile or lean you do agile and lean. The only question is how explicitly you use ideas that draw directly from lean manufacturing.

MF Bliki: AgileVersusLean.

Untitled - Startup Lessons Learned — Take it with a grain of salt.

Summary (for a much more detailed article, follow the link) :

You can’t afford to have a religion.

Communication

Agile development, actually.

Distributed Development isn’t such a great idea…

Don’t file expensive patents when you are pre-seed.

Attention to Detail

Release Early, Release Often

Fire Fast

Highs and Lows — Never give up

Don’t let your start-up define you

google startup web facebook yc new ask why social app business microsoft |2.0| software world iphone video apple idea site user free vc online internet open search network year news mobile like best hacker make way good |10| ruby application time future ad top first language programming use code service vs |2007| now design rails lisp launches yahoo amazon developer over million data javascript life thing interview music us company source founder using tech python people game big work great tip most know blog job book programmer entrepreneur problem platform next website need computer better |2008| money where project own

Hacker News News.

The Web Credibility Project: Guidelines - Stanford University.

• Make it easy to verify the accuracy of the information on your site.
• Show that there’s a real organization behind your site.
• Highlight the expertise in your organization and in the content and services you provide.
• Show that honest and trustworthy people stand behind your site.
• Make it easy to contact you.
• Design your site so it looks professional (or is appropriate for your purpose).
• Make your site easy to use — and useful.
• Update your site’s content often (at least show it’s been reviewed recently).
• Use restraint with any promotional content (e.g., ads, offers).
• Avoid errors of all types, no matter how small they seem.

Mozilla Labs » Blog Archive » Introducing Ubiquity.

Seems v. promising firefox extension .. allows users to do their own mashups from the browser.

Seems to have a very geeky interface - keyboard command to launch ubiquity and text commands to be entered using keyboard to use it. But definitely seems quite powerful.

Official Google Blog: Search experiments, large and small.

Experimentation is a very powerful tool, and we use it very widely to test potential changes to search. At any given time, we run anywhere from 50 to 200 experiments on Google sites all over the world.

Martin Fowler’s commentary on why cheaper talent is more expensive !

Naturally better programmers cost more, either as full-time hires or in contracting. But the interesting question is, despite this, are more expensive programmers actually cheaper?

…

If the cost premium for a more productive developer is less than the higher productivity of that developer, then it’s cheaper to hire the more expensive developer. The cheaper talent hypothesis is that the cost premium is indeed less, and thus it’s cheaper to hire more productive developers even if they are more expensive.

…

The trouble is that that assumption assumes productivity scales linearly with team size, which again observation indicates isn’t the case. Software development depends very much on communication between team members. The biggest issue on software teams is making sure everyone understands what everyone else is doing. As a result productivity scales a good bit less than linearly with team size. As usual we have no clear measure, but I’m inclined to guess at it being closer to the square root. If we use my evidence-free guess as the basis then to get double the productivity we need to quadruple the team size. So our average talent team needs to have forty people to match our ten talented people - at which point it costs twice as much.

…

Agile development further accelerates this effect. A talented team has a faster cycle time than an average team. This allows the full team to explore options faster: building, evaluating, optimizing. This accelerates producing better software, thus generating higher value. This compounds the time-to-market effect. (And it’s natural to assume that a talented team is more likely to produce better software in any case.)

Faster cycle time leads to a better external product, but perhaps the greatest contribution a talented team can make is to produce software with greater internal quality. It strikes to me that the productivity difference between a talented programmer and an average programmer is probably less than the productivity difference between a good code-base and an average code-base. Since talented programmer tend to produce good code-bases, this implies that the productivity advantages compound over time due to internal quality too.

…

So I understand the situation but don’t accept it. I believe that if the software industry is to fulfill its potential it needs to recognize the cheaper talent hypothesis and close the gap between high productivity and higher compensation.

Sad .. but probably necessary under the current economic scenario.

After six Nobel Prizes, the invention of the transistor, laser and countless contributions to computer science and technology, it is the end of the road for Bell Labs’ fundamental physics research lab.

…

Bell Labs was one of the last bastions of basic research within the corporate world, which over the past several decades has largely focused its R&D efforts on applied research — areas of study with more immediate prospects of paying off.

Without internally funded basic research, fundamental research has instead come to rely on academic and government-funded laboratories to do kind of long-term projects without immediate and obvious payback that Bell Labs used to historically do, says Lubell.

…

For Bell Labs, yet another chapter in its storied history of comes to a close taking the once iconic institution closer to being just another research arm of a major corporation.

Very nice commentary on why it is difficult to take up automated unit testing in many shops (with a slight focus on Java shops)

The question remains, however; is unit testing doomed? The answer to this question, of course, depends on your point of view, baby– or more precisely, what kind of development you are currently performing. For, as Andrew noted, if you are currently practicing Agile development, where unit testing has taken a strong hold and where “developers write hundreds of small tests for exercising their own code” the answer to the former question is a resounding no!

…

The reality of the Java market though, is that there is an entire throng of people who didn’t (or couldn’t) jump on the JUnit bandwagon all those years ago– this crowd is largely maintaining enterprise applications that are, simply put, incredibly hard to unit test, man. In these organizations, I have found that, more often than not, this is where the battle for tried and true unit testing is being lost.

…

Think about it for a second– unit testing is the elephant in the room. You’ve just been asked to eat it. But you can’t just take a steak knife and fork and start eating– the elephant is still alive looking right at you. No, you’ve got to first kill it, cut it up, cook it, etc. No wonder few people eat the elephant. Burger King is around the corner! No wonder unit testing often times seems doomed. We have a QA team that finds bugs!

Indubitably, these development teams are forced to rely on late cycle testing or at best, in the short term, can of course build up a hip suite of higher level tests. As a matter of fact, this is probably the best place to start! Can’t isolate that Account object for unit testing? No problem, bite the bullet and code an integration test– just make sure you realize you’ve got to handle the myriad dependencies associated with that business transaction (think a properly seeded database, etc).

…

As I said, if unit testing, as it is defined within the context of TDD, is an elephant for you and your organization, then it

is likely to remain a niche solution, found at organizations that really understand its value and progressively adopted by sites that can no longer stand the long debug cycles.

The answer to most questions depends on your point of view– if you are working on a team that has embraced agile principles, unit testing is alive and well. It’s a healthy practice that when questioned brings extreme consternation to those who’ve drank the Kool-Aid.

If you find yourself working on a legacy code base, your answer might be somewhat different– indeed, unit testing in these cases is not as easy as downloading JUnit and coding away. It’s a sizable elephant that a culture has to collectively figure out how to eat. And that takes time, commitment, and a lot of discipline. If you can’t get a handle on those three aspects, then yes, unit testing is doomed. Can you dig it, man?

FriendFeed Blog: Simple Update Protocol: Fetch updates from feeds faster.

A nice article providing an overview of SEDA architecture and showing an example of building an application using the same along with tomcat and mule, and benchmark results thereof

I don’t have even the remotest clue of what is likely to have gone wrong here .. but just seems to prima facie suggest one more situation where sites in production requiring to have automated test cases to help test all upgrades.

PS : This group seems to have a nice feature indicating the user sentiments - smileys (or should we call it frowneys)