Note that this article, “How Software Companies Die,” was written back in 1995. It seems to me that not much has changed since then, especially if the software companies haven’t adopted Agile practices. I’m not saying Agile is the answer, but there’s more to it than that. Read the article and you may be inspired to build the next Google!
The SPO threat detection system made by QinetiQ measures waves “naturally emitted by the human body,” exposing “cold” objects such as metal, plastic, or ceramics concealed under clothing. A red light on the system’s display alerts the operator if you’re packing, so there’s no need to rely on interpreting images on a screen. It also means no one is ogling your naked body, which was one of the objections when similar technology was deployed at Phoenix Sky Harbor Airport last October.
You can run, but you can’t hide! You can read more about it here.
It’s been brought to my attention that many people, perhaps all people :), did not get that I don’t really believe/practice what I coined “Development Driven Development”, which had it’s fat penguin debut here. I wrote it from the approach of “what could out agile agile” and what if it had very little to do with actual agile techniques even thought it was claiming to be such.
I definitely believe there are benefits of agile practices in software development and use several of them. I had also just read the Tom Gilb’s “evolutionary delivery,” a great improvement over its successors post at Lean Software Engineering and had just learned about a new agile practice that I hadn’t known about before. This got me thinking that I need my own agile solution. :)
In my limited knowledge I have to agree with Corey Ladas thoughts:
There’s something odd about a software culture that is so obsessed with novelty and technological determinism that it perpetually loses the knowledge of the past in an endless pursuit of the reinvention of the wheel. The race in the 2000’s to “out-agile” each other and distance ourselves as far as possible from any crusty old notions of “software engineering” in the flight from some phantom bogeyman of the “waterfall” has resulted in the neglect of a great deal of hard-fought knowledge and wisdom from the great systems engineers of the 1960’s-1980’s. It’s our loss. We’re forgetting things that are better than what we think we know now.
I wonder why this seems so true in software land. Maybe it relates to the developers constant search to learn new and exciting programming languages, tools, operating systems, techniques? Part of survival and coming up with elegant, deployable solutions is having a grasp on the “new goods” in the field. It also, however, depends on knowledge of what has already been done with success and failure in the past and there are many great books on these topics. There must be a large number of developers and managers out there with “hard-fought knowledge and wisdom” who are also practicing agile techniques and merging them together in productive ways.
Development Driven Development (DDD), not to be confused with Domain Driven Design, is a fairly new software development process that’s been gaining a considerable amount of traction in the last few months. While DDD stems from the core lean and agile methodologies, it takes a slightly different approach, which I’ll be summarizing here, to project management than the practices that currently fall under the agile umbrella.
DDD’s sole focus is on the development of software being development. Instead of focusing on the domain, features (FDD), behavior, quick development/test/release cycles, or the customer, focus is placed solely on development. The best way to explain this is via a short example. You have a customer or marketing team saying exactly a, b, and c are required. This is your requirement list. It should be conveyed to the development team very casually, preferably when they are still busy with their current round of DDD. This may sound like it would be highly ineffective, however, it avoids distracting developers (all of which are potentially in the flow/zone) and keeps from providing them with a direction or amount of information that could inhibit creativity.
A core principle of DDD is that other project management and development models entail too much mental overhead to implement successfully. By omitting these overheads the development team is free to quickly and blindly develop whatever is dreamt up on any whim. With all of the saved brain cycles they will be able to develop at such rapid pace that when the software is finished and potentially completely unusable the team will have plenty of time to start over with a much better idea of what the end result should actually be. Since they will be using DDD for the next iteration they will most likely finish in a similar situation as they were in at the end of the first cycle, but with an even clearer idea of the scope of the problem and will be that much closer to a working solution.
Since DDD is extremely rapid and involves many, many iterations, it is clearly more agile than even agile is capable of being, hence earning the name aagile. Aagile (pronounced by extending the amount of time spent saying the a) is the only proper way to refer to DDD and will help keep it from being clumped into the bucket of common agile development techniques.
If you have any DDD success stories I would love to hear about them and what key DDD principles helped make them a success.
Perl's cryptic syntax, powerful regular expressions, and "dynamicness" are more useful than I've previously given it credit. :). As a bonus it's in Christmas colors courtesy of my syntax highlighter.
Interestingly enough my markup module chooses to remove the trailing pipe "|" from line 19 in "VIEW PLAIN TEXT". So if you want to run it you can either copy it from here or use your text editors fancy block select cut feature to remove the line numbers from the html view. :)
From 37signals,
Overall storage stats (Nov 2007)
* 5.9 terabytes of customer-uploaded files
* 888 GB files uploaded (900,000 requests)
* 2 TB files downloaded (8,500,000 requests)Server stuff
We’re currently upgrading our server infrastructure to use significantly faster hardware along with the Xen virtualization software, so we’ll have fewer servers to manage. Our current server cluster contains around 30 machines, ranging from single processor file servers to 8 CPU application servers, for a total of around 100 CPUs and 200GB of RAM. Over the next couple of months, we plan to reduce the number of servers to 16 with around 92 CPU cores (each significantly faster than what we use today) and around 230 GB of combined RAM. Not only will our applications run faster, but our cluster will be much simpler to manage when we’re done.
Here's another reference from High Scalability.
The January 2008 issue of Popular Mechanics has a piece on surveillance cameras:
Security expert Bruce Schneier says that it is naive to think that we can stop these technological advances, especially as they become more affordable and are hard-wired into everyday businesses.
Excellent read. :)
My goodness! That's alot of money per hour. Read here on how Paypal is running a grid of 4000 Redhat Linux boxes.
PayPal takes Red Hat Enterprise Linux and strips out all features unnecessary to its business, then adds proprietary extensions around security. Another virtue of the grid is that PayPal's 800 engineers can all get a copy of that customized system on their development desktops, run tests on their raw software as they work, and develop to PayPal's needs faster because they're working in the target environment.
Lo and behold after I performed a "gem update" tonight, I started seeing rails 2.0 being installed! WOOHOO! Let the games begin! It's a good christmas afterall! :)
UPDATE, Part 2: Activeresource finally showed up in the mirrors and it is now installed. Rails is running perfectly! Awesome!
UPDATE: Oop, I spoke too soon:
ERROR: While executing gem ... (Gem::GemNotFoundException)
Could not find activeresource (= 2.0.0) in any repository
:(
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.
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.
Ruby is not some bachelor’s party with a foxy lady in a sherlock holmes hat. Enjoy the clarinet _why. link
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.