Software is critical to any modern business. So the key to success of any startup is to have rock star technical team that can quickly turn the vision into a piece of software and then evolve it and iterate it until it turns into a real business.
What an excellent article! This is a must read if you do coding and want to form your own startup.
Google employees use many of the tools Google produces. They even have launched an internal “dogfood” campaign in 2006. But what they see may be newer versions of the services than those released to the outside.
If a Google employee encounters trouble with any Google tool, they can call their internal support hotline named “Tech Stop.” The hotline promises 24-hour availability.
That’s awesome to hear that Google eats its own dogfood! That means the products they produce are being used by their own employees. Truly amazing. Can’t say that many software shops eat their own dogfood. Furthermore, their inhouse support is awesome. Here’s more details on what’s going on inside Google’s intranet and their remote offices.
If you are currently working as a programmer, what kind of a programmer are you? an “80%” or “20%”? If you’re not familiar with these types, you may want to read this or that.
Here’s a snippet from iBanjo:
The 20% folks are what many would call “alpha” programmers — the leaders, trailblazers, trendsetters, the kind of folks that places like Google and Fog Creek software are obsessed with hiring. These folks were the first ones to install Linux at home in the 90’s; the people who write lisp compilers and learn Haskell on weekends “just for fun”; they actively participate in open source projects; they’re always aware of the latest, coolest new trends in programming and tools.
The 80% folks make up the bulk of the software development industry. They’re not stupid; they’re merely vocational. They went to school, learned just enough Java/C#/C++, then got a job writing internal apps for banks, governments, travel firms, law firms, etc. The world usually never sees their software.
Most of you have probably seen tai chi demonstrated in slow motion. Many of those instructors only teach the health aspects of the art, essentially a watered-down version of this martial arts. At a higher level of tai chi, it’s fast and brutal; the health aspects is just a side effect of practicing this art. Watch this clip and see what “real” tai chi is all about…
The above video clip is from Sifu Wong instructional dvd. Here’s a review of it.
Disclaimer: I have no affliation whatsoever in promoting these instructional videos. However, I am promoting that tai chi is a martial arts system and it should be treated as such. Thank you.
….a Nissan GT-R!
Check out this promo from the LA Auto show. Pay attention to how the GTR engine is built and gaze at the electronic gauges that are almost stuff from Star Trek or the Space Shuttle. :)
If you want more technical details about the car, follow this jump.
Secure by design, this USB key is encrypted using AES, is waterproof, and it even has an embedded Mozilla Firefox browser. If someone tries to hack it, it will self-destruct. Check out the demo (in Flash) and be amazed.
In “Implementing Toyota’s Product Development System,”
[Toyota engineers’] overarching goal is to generate a constant flow of new products, so instead of assigning a team to focus on developing one in particular, work is concentrated at the subsystem level. The idea is that subsystems can be mixed and matched to create a whole host of possible new products, fostering creative possibilities.
and…
This approach has definite advantages when a new product reaches the testing stage. If a subsystem proves unworkable, a proven subsystem is always available, which eliminates the need to double back. All knowledge is captured and reused in future projects.
Even acknowledging that something won’t work is good because it identifies a path for engineers to avoid in the future.
Toyota Development System virtually eliminates risk and promotes a myriad of creative possibilities for new products.
This can also be applied to software development, as part of the agile process.
When the CIO of Google, Dr. Douglas Merrill, speaks, you listen…
From Jay Fields…
Knowing that Erlang is a language designed to take advantage of multi-cores is enough to drive interest. Other questions that I would expect from CIOs are: Reliability? Nine nines uptime[1]. Maturity? It’s been around for 20 years. Who else is using it? Ericsson, Nortel, T-Mobile. The argument sounds compelling.
To those naysayers about using this language (you know who you are! I’ll be haunting you at night, especially today is Halloween! :),
The AXD301 has achieved a NINE nines reliability (yes, you read that right, 99.9999999%). Let’s put this in context: 5 nines is reckoned to be good (5.2 minutes of downtime/year). 7 nines almost unachievable … but we did 9. (http://www.pragmaticprogrammer.com/articles/erlang.html)
Rock on, Erlang!
There’s a NY Times article on Google’s “20% time” that gives engineers time to work on their own projects that they’re interested in, other than working on their day-to-day projects.
Here’s some key points taken from the article:
1. “People work better when they’re involved in something they’re passionate about, and many cool technologies have their origins in 20 percent time.”
2. When people are interested in the same thing, they will self-organize (a pinciple of agile process).
3. “If you have a great technical idea, you don’t have your V.P. send out a memo telling everybody to use it. Instead, you take it to your fellow engineers and convince them that it’s good. Good ideas spread fast, and this approach keeps us from making technical mistakes. But it also means that the burden falls upon you to spread your idea.
4. “When you give engineers the chance to apply their passion to their company, they can do amazing things.”
Another good read from Test Obsessed.
Here’s some key points from the blog entry:
1. “TDD tests are unit and sometimes code-level integration tests. But TDD itself is a development approach rather than a testing approach.”
2. Distinction between developer tests and acceptance or system tests — developer tests are code-facing, and a result of TDD; and acceptance tests are business-facing.
**Note: One of the mistakes that Agile teams tend to make is attempting to substitute unit tests for acceptance tests, or vice versa.
3. Being Agile means delivering a continuous flow of value. To achieve that continuous flow of value, we have to use development practices that provide the visibility and feedback needed to make frequent, incremental changes.
4. “Mary Poppendieck says that speed requires discipline. I extend that to agility in general: if you want your team to be Agile, it must also be disciplined. Agile doesn’t mean “do whatever feels good.”
5. “Many teams have found that embedding XP-like practices within Scrum is an incredibly powerful combination.”
6. “The bottom line: automated testing at all levels can be difficult, but the alternatives are worse. Without automated testing, both code-facing and business-facing, the manual testing burden becomes too large, the team begins incurring technical debt, and velocity slows.”
By the way, here’s another good read that came from one of the comments, testing.
From O’Reilly Radar,
The survival of most projects depend on working software, at least initially, and so if there is money or time many people will spend it on development. Unfortunately, people say they will “figure that ops stuff out soon”, but what they mean is “when we’re totally screwed!!!” It doesn’t have to be that way…
The blog entry mentions Puppet, a system configuration management/server automation tool written 100% in Ruby. We’re using that at work. It’s awesome. :)
Here are some links I gathered from that article on using Puppet:
I have always been interested in security. Tonight I ran across this post publicizing the white paper on cross-build injection (XBI) vulnerabilities. Some of the listed examples of XBI attacks were OpenSSH, Sendmail and Irssi. If you build software, you definitely want to read this paper and find out the recommendations to mitigate your risk from this kind of attacks.