Kas Thomas – Going on a Software-Design Feature Fast:
“Find out (via built-in analytics) what the least-used feature of your product is. Get rid of it.
[…] Replace [it] with API methods and helpful tooling (an SDK). Charge no money for the SDK.”
Ed Finkler – The MicroPHP Manifesto:
“I am not a Zend Framework or Symfony or CakePHP developer
[…] I like building small things that work together to solve larger problems
[…] I need to justify every piece of code I add to a project”
(I mostly agree, but I love Rush!)
Douglas Crockford in his book JavaScript: The Good Parts:
"Features have a specification cost, a design cost, and a development cost. There is a testing cost and a reliability cost. The more features there are, the more likely one will develop problems or will interact badly with another. In software systems, there is a storage cost, which was becoming negligible, but in mobile applications is becoming significant again. There are ascending performance costs because Moore's Law doesnt' apply to batteries. Features have a documentation cost. Every feature adds pages to the manual, increasing training costs."
Ray Ozzie – Dawn of a New Day (his 2010 Microsoft farewell memo):
"Complexity kills. Complexity sucks the life out of users, developers and IT. Complexity makes products difficult to plan, build, test and use. Complexity introduces security challenges. Complexity causes administrator frustration.
And as time goes on and as software products mature – even with the best of intent – complexity is inescapable.
[…] In our industry, if you can imagine something, you can build it. […] And so, the first step for each of us is to imagine fearlessly; to dream."
Network World – The Google-ization of Bechtel:
"Dubbed the Project Services Network, Bechtel's new strategy applies the SaaS computing model internally to provide IT services to 30,000 users, including 20,000 employees and eventually 10,000 subcontractors and other business partners.
We operate "as a service provider to a set of customers that are our own [construction] projects," Ramleth said. "Until we can find business applications and SaaS models for our industry, we will have to do it ourselves, but we would like to operate with the same thinking and operating models as [SaaS providers] do."
[…] Bechtel turned to Salesforce.com for its expertise in running a single application with millions of users. In contrast, Bechtel operates 230 applications, and it runs 3.5 versions per application, which means it maintains approximately 800 applications at any given time.
"When you look at Salesforce.com, not only are they running one application, but they are running one version and they are only running it in one location," Ramleth says. "They upgrade that application four times per year, and they don't disrupt the users by having to retain them. Every time we have a new version, we have to retrain our users.""
Gojko Adzic – Lazy web sites run faster:
"Clever choice of asynchronous processing is definitely one of the most important decisions in any enterprise system. This is especially true for Web sites, where it absolutely plays a key role. Here are a few ideas to think about when deciding how to split the work."
Also by Gojko Adzic – Messaging is not just for investment banks:
"A messaging solution might help to divide and conquer, isolating parts of the system so that they don’t really care about each other. It also makes the system easier to scale and extend. The agents can just publish requests to a message queue, not caring about who and where will actually process them. A number of different processes, running on different machines, can pick up requests and service them, pushing the results back to the message queue. The results might be delivered back to the original requester or picked up by another worker to continue or complete the job."
Kurt Cagle at O'Reilly News – Drupal as Open Architecture:
"One thing that's rubbed at me for a while is that Ruby on Rails is still based upon this paradigm that you have to write code in order to build a site, which means that Ruby will always be of use only to those people who can write Ruby code in the first place.
With Drupal, that's no longer a requirement, and it means that people can get Drupal sites up and running quickly without needing to understand the first thing about programming - and if they can't find a module that does what they need […] then they can find a programmer that will create just that functionality without having to rebuild the entire site. It's one of the reasons why Drupal is beginning to become the de facto environment for smaller news organizations and PR departments.
[…] As to Drupal, it has effectively become to web portals what Eclipse is to application development, and has the potential to significantly challenge Microsoft's Sharepoint or similar commercial portal applications in that space."
Eugueny Kontsevoy - Web vs Desktop Nonsense:
"If a web application does not really need to run inside the browser, why does everybody expect Microsoft to ship an online version of their popular Office suite in the fashion similar to Google Docs? Technically speaking, to release a viable web version of Office they may just add an HTTP storage support with basic collaboration features into Word and Excel. Such product would run only on Windows and Macs which makes it similar to the web version of QuickBooks.
Can we see past the browser? Can we accept that browser is just a runtime library that most people do not need to download to consume your application? If so, then rendering Google Docs obsolete should be as simple as picking a more powerful platform to develop for.
[...] I want a real web-platform to build on. Google docs and Zoho Apps are a joke - their "word processors" are weaker than WordPad, which appeared in Windows 95 and had always been nothing more than a "toy editor" ever since. Now you stick THAT into a browser and declare it an Office killer just because I can access my primitively formatted documents from anywhere? Come on, the "anywhere" part should not come at expense of losing 90% of other features."
(via chromatic - The Magic of Web Apps is HTTP, Not the Browser)
Jason Fried - Ask 37signals: Is it really the number of features that matter?:
"It’s not so much about consciously saying “we have three too many features here” it’s about saying “let’s solve most of this problem with less code and simpler design.” If we need to solve more of the problem later we can, but let’s solve most of it now—and quickly. And most of the time the partial solution is the plenty solution.
So remember: Good software is about balancing value and screen real estate and understanding and outcome."
John Cowan - Third normal form for classes:
"If the state can be partitioned into two non-overlapping sub-states such that no methods depend on both of them, then the class should be refactored into two classes with separate states. This also improves encapsulation, as the methods in one class can now be changed without regard to the internals of the other class."
Sam Ruby - Dare Takes a Look at CouchDB:
"What happens when your application grows so large that you have no choice but to massively employ techniques like sharding? What do you have to give up? What do you need to add back in in order to mitigate the loss of the things you give up?
At a certain point, referential integrity has to be given up. Scale a bit further, and even the notion of a relation in the relational database sense of the word starts to break down. To cope, you denormalize a bit, not so much for performance reasons (though that’s important too), but as a self defense mechanism so that the pieces of data that you do have have enough context to be meaningful."
"Here’s my long bets for the moment, with the only caveat that in some cases I pick specific implementations as exemplars of a larger field.
Joe Gregorio - ETech '07 Summary - Part 2 - MegaData:
"If you want to scale to the petabyte level, or the billion requests a day, you need to be:
Those constraints represent something fundamentally different from a relational database."
Joel Spolsky - The Big Picture:
"The only thing harder than trying to design software is trying to design software as a team.
I can’t tell you how many times I’ve been in a meeting with even one or two other programmers, trying to figure out how something should work, and we’re just not getting anywhere. So I go off in my office and take out a piece of paper and figure it out. The very act of interacting with a second person was keeping me from concentrating enough to design the dang feature.
What kills me is the teams who get into the bad habit of holding meetings every time they need to figure out how something is going to work. Did you ever try to write poetry in a committee meeting? It’s like a bunch of fat construction guys trying to write an opera while sitting on the couch watching Baywatch."
Jason Pontin interviews Bjarne Stroustrup at Technology Review - The Problem with Programming:
"In theory, the answer is simple: educate our software developers better, use more-appropriate design methods, and design for flexibility and for the long haul. Reward correct, solid, and safe systems. Punish sloppiness.
In reality, that's impossible. People reward developers who deliver software that is cheap, buggy, and first. That's because people want fancy new gadgets now. They don't want inconvenience, don't want to learn new ways of interacting with their computers, don't want delays in delivery, and don't want to pay extra for quality (unless it's obvious up front--and often not even then). And without real changes in user behavior, software suppliers are unlikely to change.
We can't just stop the world for a decade while we reprogram everything from our coffee machines to our financial systems. On the other hand, just muddling along is expensive, dangerous, and depressing."
Pete Lacey - They can’t hear you:
"Maybe you don’t work for or with a Global 2000 company, so I’ll let you in on a little secret: They Can’t Hear You! That’s right, the CIOs, and Enterprise Architechts, and, yes, even the journeyman programmer employed by these firms have no idea that there’s even a discussion going on. [...] And the typical corporate technologist (broad strokes here, of course I don’t mean you) hasn’t considered REST and decided against it, they haven’t even heard the term. Ditto RelaxNG, Django, Atom, and everything else that makes the Web work and makes working with the Web easy.
[...] Business-oriented technologist refuse to beleive that simple solutions apply to their problem set. It’s always been complex before, and gosh darnit, it’s gonna stay that way. They want transactions, and reliability, and asynchronous messaging, and orchestration, and everything else. If it doesn’t look like Rendezvous or Tuxedo or BizTalk, then it can’t be a business grade solution, therefore it must be some toy."
Frederick P. Brooks (in 1987)- No Silver Bullet:
"The familiar software project, at least as seen by the nontechnical manager, has something of this character; it is usually innocent and straightforward, but is capable of becoming a monster of missed schedules, blown budgets, and flawed products. So we hear desperate cries for a silver bullet--something to make software costs drop as rapidly as computer hardware costs do.
But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity. In this article, I shall try to show why, by examining both the nature of the software problem and the properties of the bullets proposed.
[...] Software people are not alone in facing complexity. Physics deals with terribly complex objects even at the "fundamental" particle level. The physicist labors on, however, in a firm faith that there are unifying principles to be found, whether in quarks or in unifiedfield theories. Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary.
No such faith comforts the software engineer. Much of the complexity that he must master is arbitrary complexity, forced without rhyme or reason by the many human institutions and systems to which his interfaces must conform. These differ from interface to interface, and from time to time, not because of necessity but only because they were designed by different people, rather than by God."
(Via Joel Spolsky.)
Alan Kay back in 1998 - prototypes vs classes was: Re: Sun's HotSpot (via M. David Peterson):
"The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase). The Japanese have a small word -- ma -- for "that which is in between" -- perhaps the nearest English equivalent is "interstitial". The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Think of the internet -- to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas."
Jon Udell - A new breed of highly-available serverless applications:
"Bill Seitz alerted me to one of those footpaths the other day: Les Orchard's S3-backed wiki. Outstandingly cool! For those who have not followed the various plot threads closely, this is an evolution of the idea of the serverless wiki. [...] Les has substituted Amazon's S3 network storage for the local disk. It's a wonderful hack that anticipates a whole new breed of highly-available serverless applications."
W. Eliot Kimber - XML Content Management the Dr. Macro Way: Simple Is Good:
"The key lessons I took away from this experience and that drive all my thinking about content management are:
1. Manage the XML source as versioned storage objects
2. Do all semantic processing, including link managing, metadata indexing, etc. as separate activities on top of or separate from the core storage
3. All of the complexity in XML content management is concentrated at the boundary between the repository and the outside world and that is where the system's complexity should likewise be concentrated.
[...] Can I implement all the functionality required using Subversion (nee CVS) and XSLT (possibly with a few extension functions to handle specialized business logic, such as connecting to another, pre-existing information system)?
That is, can I prove my understanding of the requirements and business processes through the implementation of a system using a brute force mechanism?
If the answer is yes, then the next question is, why don't you?"
Tim Bray - No Database!?:
"I like the semantics of the Unix filesystem, and I also really like the fact that whether you’re talking ufs, ext3, zfs, or whatever, this is some of the world’s most thoroughly-debugged and battle-hardened code. Also, most modern operating systems are really quite clever at noticing when part of the filesystem is getting hammered and caching the whole thing in memory, so you may never go near a disk.
I’m not religious—I’ve deployed runtime databases where I’ve had to. But there is a psychology out there in our profession,which says: if you have data that you want to store and retrieve, that means you need a database. But sometimes you don’t. And sometimes you come out ahead on one or both of the less-work and runs-fast metrics by not having one."
Nathan Torkington - A Week in the Valley: Ning:
"It's just like Rails in the sense that it makes it easy to build a web app. Rails puts "hello world" one commandline away. Ning puts a full real big app one click away. Rails is a framework built around conventions. Ning is a set of libraries, and Ning apps are built using those libraries. There's actually less of a learning curve for programmers in Ning than there is in Rails.
[...] Their storage engine is interesting. Every object has ID, app, user, tag, and type as metadata, and holds arbitrary key-value pairs. That's all the storage engine does, so it's very web loose-coupled. If your appointment data points to my address data, I can delete my address data and your appointment's left pointing to nothing."
Tim O'Reilly cites Ian Wilkes in Web 2.0 and Databases Part 1: Second Life:
"Like everybody else, we started with One Database All Hail The Central Database, and have subsequently been forced into clustering. However, we've eschewed any of the general purpose cluster technologies (mysql cluster, various replication schemes) in favor of explicit data partitioning. So, we still have a central db that keeps track of where to find what data (per-user, for instance), and N additional dbs that do the heavy lifting. Our feeling is that this is ultimately far more scalable than black-box clustering."
Follow-ups: Database War Stories #2: bloglines and memeorandum, #3: Flickr, #4: NASA World Wind.
Koranteng Ofosu-Amaah - The REST Elevator Pitch:
"I've recently been thinking about defining the hardest problems I've encountered in software engineering, my cursory top 10 list:
Now I'm not a database person so I handwaved away all of those data peoples' worries in one word: persistence."
Tim O'Reilly at O'Reilly Radar: "Here's a reading list of links to summarize the discussion at the Reading 2.0 summit held today in San Francisco."
Kurt Cagle - Thoughts on Complexity:
"Over the years, I've noticed that in programming, as in other systems, there seems to be a fairly invariant rule out there: You can never eliminate complexity from a system, you can only move it from place to place. or, put another way, In any program, someone will have to deal with the mess when it hits the fan. This is part of the reason why I have become convinced that the profession of programmer will always be needed."
Phil Windley reports a talk by Alan Kay: Is Computer Science an Oxymoron?:
"Engineers should read a book about how the Empire State building was done. Including the demolition of the building on the site before, the Empire State building was built in 11 months by 3000 people. We don’t know how to do this in computing. Whatever we think engineering is, it can’t mean the modern use of the term. I don’t know of a single computing system that is attached to you that if it fails it will almost certainly kill you. That’s what happens with jet engines. That’s engineering.
[...] We’re much better at building software systems than we are at predicting what they will do. There are no good models. If we were scientists, we’d be trying to build models."
Stephen O'Grady - Speed is a Feature:
"A big part of the equation that is Google is speed, pure and simple. Very low latency performance, delivered from their secret sauce architecture. [...] The interesting thing is that speed is not traditionally considered a feature, per se. It's a design consideration, to be sure, but in the applications I've developed speed has rarely been a part of the requirements gathering phase - apart from occasionally defining what consitutes unacceptable performance (greater than 8 second load times on web pages, for example).
[...] What's the catch in all of this? Speed is [much] easier said than done, and depending on the application type might be near impossible for smaller players to deliver on cost constrained hardware platforms."
Tim Bray - The Real AJAX Upside:
"Pretty well all Web-publishing software does lots of templating and dynamic page generation, and pretty well all of it is piggish, stressing out servers (and, to be fair, representing a pretty good business opportunity for my employer). I suspect there’s a huge system-wide optimization waiting out there for us to grab, by pushing as much of the templating and page generation work out there onto the clients."
Make sure to take a look at Harry Fuecks' presentation slides AJAX@localhost [PDF] if you're at all interested in AJAX... (Sam Ruby would probably have used the title '"Just" use AJAX' instead)!
Harry Fuecks at SitePoint - MVC and web apps: oil and water:
"CRUD is defined in the context of databases where what you’re dealing with is sets of information—you need to make a distinction between inserting into the set and updating an existing member of the set.
Meanwhile HTTP was designed for access to resources, the “primary key” being determined by it’s URL (vs. having to worry about the insert id). If you think “documents”, it’s clear there’s no need to make a distinction between creating and updating—creating a document results in the first version. Updating means overwriting an existing document with a new version. But in both cases the client is POSTing the same thing and does not need to be aware of whether the document already existed or not.
[...] Perhaps our websites have been driven too far by the database? The point here is, given the mismatch between HTTP and CRUD, we’ve put CRUD first which in turns makes actions first class in our frameworks. We aim to support N different types of action (verbs) when really we should have been dealing with only three—GET, POST and DELETE (the latter being perhaps re-routed to a specific “resource class” method according to some framework / form conventions)."
John Lim - The fine art of programming:
“Here’s a list of excellent online programming guides that i am compiling.”
Michael Nash at developer.com - Decoupling Application Logic, Persistence, and Flow: The Model Technique:
“The next step beyond separation of persistence and business logic can be the separation of the application control flow. Business logic classes in this case are written in such a way that they are unaware of how they were called, or what business logic element will be called next. They still require certain inputs, of course, and produce results in some fashion (again, often using the bean pattern to allow result properties to be accessed), but they are a single link in a chain. Some external mechanism is used to control application flow, either another class, or a driver class that reads the sequencing and navigation information from configuration.
[…] Long-time users of Unix-style operating systems will be familiar with the pattern described here, as it is a lot like the Unix command philosophy: Keep each command simple, make it do one thing and do it well, and provide a powerful means to assemble multiple commands into complex applications. In the Unix world, this is achieved by shell scripts and the pipeline technique. The same ideas can be applied to Java applications, with similar powerful results.
Many developers, of course, will recognize this technique as the beginnings of a full workflow pattern, where application logic steps can be combined in sequences or “flows” as required, and where the decisions at each step as to what the next step should be (or what the choices for next steps are, if there are several), are in fact left up to the workflow engine, driven by a sophisticated configuration file. This configuration file can even in many cases be created graphically, allowing a developer to literally draw the sequence of operations of the application required, drawing more and more from a pool of re-usable business logic components, and inventing each individual wheel only once, instead of repeatedly.”
Paul Prescod - Reinventing Email using REST:
“As an educational tool, this article will describe how to re-engineer a familiar application, email, as a Web Service using HTTP and the principles of Web Architecture and REpresentational State Transfer.”
Adam Bosworth at ACM Queue - Learning from THE WEB:
“Successful systems on the Web are bottom-up. They don’t mandate much in a top-down way. Instead, they control themselves through tipping points. For example, Flickr doesn’t tell its users what tags to use for photos. Far from it. Any user can tag any photo with anything (well, I don’t think you can use spaces). But, and this is a key but, Flickr does provide feedback about the most popular tags, and people seeking attention for their photos, or photos that they like, quickly learn to use that lexicon if it makes sense. It turns out to be amazingly stable.
[…] It is time that the database vendors stepped up to the plate and started to support a native RSS 2.0/Atom protocol and wire format; a simple way to ask very general queries; a way to model data that encompasses trees and arbitrary graphs in ways that humans think about them; far more fluid schemas that don’t require complex joins to model variations on a theme about anything from products to people to places; and built-in linear scaling so that the database salespeople can tell their customers, in good conscience, for this class of queries you can scale arbitrarily with regard to throughput and extremely well even with regard to latency, as long as you limit yourself to the following types of queries. Then we will know that the database vendors have joined the 21st century.”
Neil Kandalgaonkar - Links to essays in Best Software Writing I:
“Joel Spolsky has compiled a book of essays on software, which he calls The Best Software Writing I. The essays all came from online sources, but when Spolsky released the chapter listing, I didn’t see anywhere online where he posted links to the originals. So here they are.”
Scott Berkun at ONLamp.com - How to Decide What Bugs to Fix When, Part 1 and Part 2:
“This two-part essay is a primer on those rules and survival kits, giving you basics to follow. But more importantly, I’ll provide the core ideas needed to make your own rules. The advice is organized into four levels, from scrappy first aid (level 1) to higher-caliber planning (level 4).”
Robert Kaye - OSCON Day 0: Scalable Internet Architectures:
"One of my favorite presentations from last year was Theo Schlossnagel's presentation on Whack-a-mole, so when I saw him giving a full tutorial on scalability this year, I had to go and check it out. And this year I wasn't disappointed either -- Theo presented a solid tutorial that exuded his practical experience in this field. Of course its impossible to summarize four hours of a tutorial in a blog entry, so I'll try to summarize Theo's three simple rules that he applied repeatedly in his presentation:
1. Know the system you're trying to scale. 2. Complexity has costs. 3. Use the right tool for the job."
Micah Dubinko at XML.com - Life After Ajax?:
"Working on a crossword puzzle with ink means two things: you find yourself more conservative, (You wait until you are fairly confident before committing to something.) and when you inevitably make a mistake anyway, it gets messy to patch things up.
Software development is the same way. No matter how carefully a developer proceeds, at some point a mistake will happen, and if the erroneous code has gone out the door, you have a messy situation that needs patching. At that point, software can begin to look like a badly scribbled-out crossword."
George Schlossnagle - Why PHP Scales - A Cranky, Snarky Answer:
"In every application I've ever worked on application performance was governed by the following factors, in rough order of their importance:
Notice how PHP being naturally slower than Java (something I believe to be true) comes in last? That's a distant last."
Jon Udell - How do you design a remixable Web application?:
"A website that wants to be remixable will deliver content as XML and behavior as script. These aspects can be, and will be, combined server-side for Web 1.0 clients, but Web 2.0 clients will increasingly be able to do this processing for themselves. So there will be two ways to remix: by intercepting the server-side combination of XML content and scripted behavior, or by recombining on the client."
Murugan Pal at ONLamp.com - What Developers Want:
"Irrespective of the language programmers choose for expressing solutions, their wants and needs are similar. They need to be productive and efficient, with technologies that do not get in the way but rather help them produce high-quality software. In this article, we share our top ten list of programmers' common wants and needs."
David Megginson - Rails vs. PHP: MVC or view-centric?:
"This week, I decided to try PHP and Ruby-on-Rails for prototyping web applications (I'd never used either before). [...] So why did I like PHP so much better than Rails?"
Joel Spolsky - Making Wrong Code Look Wrong:
"The real point is that exceptions eliminate collocation. You have to look somewhere else to answer a question of whether code is doing the right thing, so you're not able to take advantage of your eye's built-in ability to learn to see wrong code, because there's nothing to see."
At ONLamp.com, Daniel H. Steinberg summarizes Adam Bosworth's keynote at the MySQL Users Conference 2005:
"Adam Bosworth suggested that we "do for information what HTTP did for user interface." [...] As a result of a simple, sloppy, standards-based, scalable platform, we have information at our fingertips from Google, Amazon, eBay, and Salesforce. Bosworth's own company, Google, gets hundreds of millions of hard queries a day. He said they see it as putting Ph.Ds in tanks to drive through walls rather than around them.
In addition to the advantages in software, there have been great gains in hardware. Bosworth said that one million dollars buys you five hundred machines with 2TB of in-memory data, a PetaByte of on-disk data, and a reasonable throughput of fifty thousand requests per second. This amounts to one billion requests per day. Having this sort of power changes the way you think."
Sam Ruby points to IBM's confession (and recommends PHP and other technologies):
"Application development using IBM programming models and tools is untenably complex. The Research Division's new Services and Software strategy includes a strong focus on radical simplification. [...] Over 70 people in IBM worldwide are currently participating in an effort to define the problem, and the scope of the solution, more precisely."
Julio M. Merino Vidal at ONLamp.com - Making Packager-Friendly Software:
"A package maintainer, or packager, is a person who creates packages for software projects. He eventually finds common problems in these projects, resulting in a complex packaging process and a final package that is a nightmare to maintain. These little flaws exist because in most cases the original developers are not packagers, so they are not aware of them. In other words, if you do not know something is wrong, you cannot fix it.
This article describes some of these common problems and possible solutions. Consequently, it is of most value to software developers who make their creations publicly available."
Joe Gregorio at XML.com - XML.com: How to Create a REST Protocol:
"If you follow web services, then you may have heard of REST. REST is an architectural style that can be used to guide the construction of web services. Recently, there have been attempts to create such services that have met with mixed success. This article outlines a series of steps you can follow in creating your protocol--guidance that will help you get all the benefits that REST has to offer, while avoiding common pitfalls."
Subversion's Garrett Rooney on ONLamp.com - Preserving Backward Compatibility:
"The first kind of compatibility most people think about is API compatibility. [...] Second is Application Binary Interface, or ABI, compatibility. [...] If your program communicates over a network, it has to deal with a third form of compatibility, client-server protocol compatibility. [...] Finally, if your program stores data somewhere, be it in a database or in files on disk or wherever, there is data format compatibility."
While working on our new web application DC5, a total rewrite of its predecessor DC4, it occurred to me that you could say there's five ways of looking at a web application, five interfaces that matter to its users.
Getting any of these right, making it beautiful, is an art in itself. Getting all of these right seems to be the ultimate goal for a web application, and should result in a wonderfully versatile and transparent piece of software:
From 2002, J. Scott Johnson's Software Engineering Practices for Large-Scale PHP Projects presentation (viewable with Internet Explorer only):
"Aspects of Large Scale Projects:
Sriram Krishnan - Tyranny of the geeks:
"Nowadays, it is the 'in'-thing to be CSS-aware. If you're dumb enough to use a table tag, you're branded as a clueless moron. However, no one really tells you why table tags are bad. In fact, the equivalent CSS for generating something like your standard sign-up form is downright scary. And with every browser (Opera, Firfox, IE) having a different idea on what 'right' CSS is, you're much safer with table tags. For those using CSS and use divs and floats to build their tables, I ask them why. Why do something that is so un-intuitive? I could teach a kid about rows and columsn.
[...] A year ago, I read up a lot on the Semantic Web and RDF. I have to admit that I didn't understand any of it. Any of it. Ontologies, RDF, OWL, what not. However, you see blogs and enclosures getting the same effect with only a fraction of the complexity. I dont need smart agents to find what I want - I just search in Google and it is usally smart enough to give me what I need. I dont have high hopes for the semantic web unless they simplify and do it real soon."
Adam Bosworth - ISCOC04 Talk:
"That software which is flexible, simple, sloppy, tolerant, and altogether forgiving of human foibles and weaknesses turns out to be actually the most steel cored, able to survive and grow while that software which is demanding, abstract, rich but systematized, turns out to collapse in on itself in a slow and grim implosion.
[...] What is more, in one of the unintended ironies of software history, HTML was intended to be used as a way to provide a truly malleable plastic layout language which never would be bound by 2 dimensional limitations, ironic because hordes of CSS fanatics have been trying to bind it with straight jackets ever since, bad mouthing tables and generations of tools have been layering pixel precise 2 dimensional layout on top of it. And yet, ask any gifted web author, like Jon Udell, and they will tell you that they often use it in the lazy sloppy intuitive human way that it was designed to work. They just pour in content. In 1996 I was at some of the initial XML meetings. The participants' anger at HTML for "corrupting" content with layout was intense. Some of the initial backers of XML were frustrated SGML folks who wanted a better cleaner world in which data was pristinely separated from presentation. In short, they disliked one of the great success stories of software history, one that succeeded because of its limitations, not despite them. I very much doubt that an HTML that had initially shipped as a clean layered set of content (XML, Layout rules - XSLT, and Formatting- CSS) would have had anything like the explosive uptake.
Now as it turns out I backed XML back in 1996, but as it turns out, I backed it for exactly the opposite reason. I wanted a flexible relaxed sloppy human way to share data between programs and compared to the RPC's and DCOM's and IIOP's of that day, XML was an incredibly flexible plastic easy going medium. It still is. And because it is, not despite it, it has rapidly become the most widely used way to exchange data between programs in the world. And slowly, but surely, we have seen the other older systems, collapse, crumple, and descend towards irrelevance.
Consider programming itself. There is an unacknowledged war that goes on every day in the world of programming. It is a war between the humans and the computer scientists. It is a war between those who want simple, sloppy, flexible, human ways to write code and those who want clean, crisp, clear, correct ways to write code. It is the war between PHP and C /Java. It used to be the war between C and dBase. Programmers at the level of those who attend Columbia University, programmers at the level of those who have made it through the gauntlet that is Google recruiting, programmers at the level of this audience are all people who love precise tools, abstraction, serried ranks of orderly propositions, and deduction. But most people writing code are more like my son. Code is just a hammer they use to do the job. PHP is an ideal language for them. It is easy. It is productive. It is flexible. Associative arrays are the backbone of this language and, like XML, is therefore flexible and self describing. They can easily write code which dynamically adapts to the information passed in and easily produces XML or HTML.
[...] I remember listening many years ago to someone saying contemptuously that HTML would never succeed because it was so primitive. It succeeded, of course, precisely because it was so primitive. Today, I listen to the same people at the same companies say that XML over HTTP can never succeed because it is so primitive. Only with SOAP and SCHEMA and so on can it succeed. But the real magic in XML is that it is self-describing. The RDF guys never got this because they were looking for something that has never been delivered, namely universal truth."
Paul Graham - Made in USA:
"Systematic" is the last word I'd use to describe the way good programmers write software. Code is not something they assemble painstakingly after careful planning, like the pyramids. It's something they plunge into, working fast and constantly changing their minds, like a charcoal sketch.
In software, paradoxical as it sounds, good craftsmanship means working fast. If you work slowly and meticulously, you merely end up with a very fine implementation of your initial, mistaken idea. Working slowly and meticulously is premature optimization. Better to get a prototype done fast, and see what new ideas it gives you."
Macworld UK - Macworld UK - Simplicity is 'next big thing' in IT - Economist:
"The Economist Magazine this week has published an IT survey, which declares the single message of simplicity Apple to have preached since its inception as "the next big thing".
"The next thing in technology is not just big but truly huge: the conquest of complexity", the Economist explains. It talks about how "most of us" find technology frustrating, infuriating and sometimes tortuous at times. The title is trying to assess the work done by the IT industry to simplify matters.
The survey looks at two recent consumer-technology successes: Apple's iPod and Google. Writer, Andreas Kluth, said: "Google and the iPod are successful because each rescues consumers from a particular black hole of complexity"."
Economist.com's tribute to Dennis Ritchie:
"Linux is also the true heir of the Unix tradition in the sense that its development process is collaborative. Dr Pike says that the thing he misses most from the 1970s at Bell Labs was the terminal room. Because computers were rare at the time, people did not have them on their desks, but rather went to the room, one side of which was covered with whiteboards, and sat down at a random computer to work. The technical hub of the system became the social hub.
It is that interplay between the technical and the social that gives both C and Unix their legendary status. Programmers love them because they are powerful, and they are powerful because programmers love them. David Gelernter, a computer scientist at Yale, perhaps put it best when he said, "Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defence against complexity." Dr Ritchie's creations are indeed beautiful examples of that most modern of art forms."
chromatic - Just Finally Do It!:
"Without further ado, here are my seven rules for Just Finally Doing It!
1. Untested code isn't done. 2. Unreleased code isn't done. 3. Undocumented code isn't done. 4. Set many, small, specific goals. 5. Simplicity gives you more options than complexity. 6. Do something every day. Finish something every week. 7. One feature finished is better than ten features planned."
Darrell M. Kienzle, Matthew C. Elder, David Tyree, James Edwards-Hewitt - Security Patterns:
"We have produced a Security Patterns Repository [PDF] consisting of 26 patterns and 3 mini-patterns. (A mini-pattern is a shorter, less formal discussion of security expertise in terms of just a problem and its solution.) We focused on the domain of Web application security to bound the scope of the problems that our patterns address."
chromatic's Pragmatic Programmers Interview:
"Andy Hunt: [...] Simple applications should be simple to write, easy to install and maintain. That used to be the case, but the current state of the world with web applications, J2EE, and so on is quite a bit more complicated than it needs to be.
Dave Thomas: Interestingly, we're seeing definite signs of pushback against the complexity. The "I'm mad as hell and I'm not going to take it any more" meme is starting to spread among developers, but it's a slow business. To some extent, the reluctance to change is only natural -- after all, folks have spent years learning the fine arcane details of J2EE and all the associated frameworks, and now they're being told that all that detail is too much. But at the same time, they're seeing the benefits of using tools such as Spring, Hibernate, Pico, and so on. We're even seeing folks abandon the J2EE world entirely in favor of lighter-weight solutions when appropriate. This wouldn't have happened two years ago, where a "Hello, World!" web app still needed 17 deployment descriptors to install. [...]
Dave: [...] Java and C# are not really dynamic in any meaningful way. Memory management is a small part of the picture, but the real gains in these more dynamic languages come from different areas, particularly from a flexible type model and from the ability to metaprogram.
Ultimately, it comes down to ease of expression. If I can express myself in code at a level closer to the problem domain, then I'm going to be more effective, and my code is likely to be easier to maintain and extend. Paul Graham makes a big deal out of the way Lisp helped him while building the software that became Yahoo Stores, and he's right. These languages, applied properly, are a strategic advantage. I know some companies are using them with great success. And you know -- they're keeping quiet about it."
Tom Baeyens on The State of Workflow:
"When talking about an RDBMS in a software development team most people will get the picture and shake their heads slightly up and down confirming they understand what you're saying. When using workflow terminology, the same crowds will shake their heads similarly but this time, every person will have a very different picture."
"[...] I really believe a WFMS [workflow management system] is the missing link in enterprise development. First of all, I want to state that the default way of incorporating business process logic into enterprise software is a scattered approach. This means that the logic of the business process is spread over various systems like the EJB-container, database-triggers, message broker and the likes. No need to mention that this leads to unmaintainable software. As a consequence, these organizations will think of changing their business process software only as a last resort. They often prefer to change their processes to the software. This argument also applies to a larger extent to ERP software packages. In a second attempt, suppose we are aware of this problem and really want to centralize all code related to one process. This is fine for one business process, but if you implement multiple processes, you see duplication of code that manages state and process variables. Then, in a third approach, we could extract the duplicated code and put it in a central library. Well, that is actually a WFMS so don't bother implementing it yourself and choose one from the list below."
Doug Ross on Return-codes vs. Exceptions:
"Software quality, in general, sucks. The reason for this is that many developers are too lazy to instrument, monitor and and respond to all sorts of strange conditions.
In other words, many of us are undisciplined. We're more worried about "readability" (and I disagree with that contention as well - but I'll get to that) than whether or not or software will kill anyone, debit the wrong account by a million bucks, or screw up the actuarial table for 83 year-old transvestites.
Like it or not, dealing with aberrant conditions is a contract we agree to when we decide to be professional and responsible software developers. Treating "abnormal behaviour inline with normal execution" is a misstatement. We need to deal with the unexpected. And the best place to do it is the place where you can "unwind" the logic that's gone bad."
Paul Graham essay on Taste for Makers:
"Relativism is fashionable at the moment, and that may hamper you from thinking about taste, even as yours grows. But if you come out of the closet and admit, at least to yourself, that there is such a thing as good and bad design, then you can start to study good design in detail."
"Intolerance for ugliness is not in itself enough. You have to understand a field well before you develop a good nose for what needs fixing. You have to do your homework. But as you become expert in a field, you'll start to hear little voices saying, What a hack! There must be a better way. Don't ignore those voices. Cultivate them. The recipe for great work is: very exacting taste, plus the ability to gratify it."
Martin Roberts on Workflow versus Process Automation: "When a Process fails where do you need to route the fault to? Normally a human - so why do most tools make this a cumbersome task? Why do these so called next generation tools find dealing with people such an alien idea? I believe the answer lies in the fact that most of these emerging tools have been built by people used to handling classes that rarely touch humans directly. They tend to be focused on the J2EE/.Net like frameworks which are low level in the inspirations and have failed to take into account the gains of the 4GL world of the early 1990's."
Jon Udell comments: "I met Martin at XML 2003 and we had a fascinating hour-long conversation. The point he makes here -- that humans are the exception handlers in automated systems, and that we need to design accordingly -- is one I've made too."
Ken Arnold on the The Sum of Ant:
"Ant is nothing more than the sum of its parts
By this I mean that ant has not learned the basic power of composition, building things out smaller parts. This was the great insight that our Unix forbearers bequeathed us toolsmiths, and it's pretty sad to see it forgotten. In Unix this is done with pipes -- the output of one program can become the input of another. Along with conventions about program output, this allows you to build up something that is more than the sum of its parts. A utility that finds file in the file system can generate a list of files for any purpose: removal, editing, rebuilding, copying, printing, ...
Ant has many kinds of tasks. These are portable because they are written in Java, and these task implementations can rely upon operating system abstractions in the underlying ant platform.
But they almost never work together. There are some common tools for building up lists of files, but if you want a list of files from any other source, good luck. This is why there are two different tasks (one optional) that calculate list of Java class dependencies, and they are incompatible. And if you want a list of Java class dependencies for a task that one of these two tasks can't handle, good luck.
A common quote in our biz is the observation that a good software tool will do things the author never expected. I doubt that writers of ant tasks are very often surprised."
Dale Asberry on the importancy of loose coupling - Why is Distributed so Hard?:
"In some ways, marriage vows do a disservice to the richer subtleties in intimate human interaction. Namely, two people don't come together to become one, they come together to become three! There will always be the self and the other. The third ingredient is the relationship itself. Unless the relationship is tended to by both people, it won't work. The most successful couples:
* address expectations through rituals (protocols) and communication * adjust to the situation * are forgiving of transgressions * interdependent, neither independent nor dependent"
At ONLamp.com, Robert Jones has lots of good advice for Planning for Disaster Recovery on LAMP Systems:
"Don't get me wrong, disaster recovery is a critical issue. It's just that it can be a very painful process for those of us who come from an informal development background. [...] I know I'm not the only one dealing with this issue so here are some ideas that you might want to build into your apps.
The problem with our sort of database applications is that they weave themselves into the Linux system configuration. We add definition blocks to the configuration files for Apache, MySQL, Samba, et al. We create system-wide environment variables in user shells and insert symbolic links into the filesystem. Every time we rebuild a system we have to make the configuration changes anew. The potential for error is large, even assuming we remember all the steps."
Jon Udell on Radical software customization:
"We can all agree that software must be customizable. But when programmers alone decide how users can do things, you often end up with a scenario like Aunt Tillie's OS X adventure: a dashboard packed with incomprehensible dials and knobs. If the dashboard was built with a dynamic language, the programmer can at least rearrange the controls more quickly and more easily. But the rules engines that James Owen has been writing about, and the FIT framework that Ward Cunningham has created, point toward a radically altered relationship between software makers and software users. It can't happen too soon."
Great article: Mike Duigou writes about Complexity.
"What could make JXTA or any technology complicated for new users? There are far too many possibilities: * Installation hell * Configuration hell * Starting hell * Documentation hell * API hell * More hells"
Most problems he describes can happen with any programming language, but this one seems Java-specific:
"When you start working with a new technology you are confronted with a vast seemingly featureless wall of API calls. Which ones do you start with? Are some preferred to others? How do I create a sub-class for a class that has 200 methods? (I recently had to make my first Swing component, a sub-class of JComboBox. I may one day recover from the experience). Perhaps most importantly, how do I begin architecting an application out of 80 classes and 500 methods that I have never used?"
This looks like I should read it once I have the time to do so: Software Engineering for Internet Applications by Eve Andersson, Philip Greenspun, and Andrew Grumet.
Russell Beattie, Rampaging Computer Science:
"The problem is that much of the Java stuff out there is just written by really smart morons who seem to love complexity for complexity's sake. Even in the API itself! Ever used the Calendar API? It's written by a monkey. Ever check out the code under the JSTL? Those guys have to be on crack. It's not the language itself that causes these problems, it's the culture around the language. When programmers respect patterns more than solutions, you know something is broken."
Clay Shirky wrote a great article on what he calls Situated Software:
"Part of the future I believe I'm seeing is a change in the software ecosystem which, for the moment, I'm calling situated software. This is software designed in and for a particular social situation or context. This way of making software is in contrast with what I'll call the Web School (the paradigm I learned to program in), where scalability, generality, and completeness were the key virtues.
[...] Situated software is in the small pieces category, with the following additional characteristic -- it is designed for use by a specific social group, rather than for a generic set of "users". The biggest difference this creates relative to classic web applications is that it becomes easy to build applications to be used by dozens of users, an absurd target population in current design practice. Making form-fit software for a small group of users has typically been the province of banks and research labs -- because of the costs involved, Web School applications have concentrated on getting large-scale audiences. And by privileging the value that comes with scale, Web School applications put other kinds of value, particularly social value, out of reach.
We've been killing conversations about software with "That won't scale" for so long we've forgotten that scaling problems aren't inherently fatal. The N-squared problem is only a problem if N is large, and in social situations, N is usually not large. A reading group works better with 5 members than 15; a seminar works better with 15 than 25, much less 50, and so on.
This in turn gives software form-fit to a particular group a number of desirable characteristics -- it's cheaper and faster to build, has fewer issues of scalability, and likelier uptake by its target users. It also has several obvious downsides, including less likelihood of use outside its original environment, greater brittleness if it is later called on to handle larger groups, and a potentially shorter lifespan.
[...] By relying on existing social fabric, situated software is guaranteed not to work at the scale Web School apps do, but for the same reason, it can work in ways Web School software can't.
[...] Situated software isn't a technological strategy so much as an attitude about closeness of fit between software and its group of users, and a refusal to embrace scale, generality or completeness as unqualified virtues. Seen in this light, the obsession with personalization of Web School software is an apology for the obvious truth -- most web applications are impersonal by design, as they are built for a generic user. Allowing the user to customize the interface of a Web site might make it more useful, but it doesn't make it any more personal than the ATM putting your name on the screen while it spits out your money."
Ephraim Schwartz at InfoWorld:
"Deloitte has developed what it calls Industry Prints for some 20-plus industries, using data gathered from Deloitte's interactions with various enterprise-level companies. An Industry Print details every single process that makes up an industry. It maps processes all the way from the 10,000-foot level (run HR, run customer support) down to specific workflows for both humans and applications.
[...] It was only after the observation process that Telispark created an application. The result wasn't a squeezed-down version of the SAP PM app, but a unique, customized solution that worked the way the techs in the field did.
Hard as it may be to believe, most mobile IT projects don't take this approach.
Most companies are so bent on getting their enterprise applications into handhelds that they forget that mobility, by its nature, changes businesses' processes and workflows -- and that change must be designed into the mobile applications themselves.
Industry Prints are a series of best-practice workflows and they, or something like them, should be square one, before anyone actually does a lick of coding. The promise of high tech has yet to be fulfilled because we continually try to adapt human behavior to the needs of technology.
Isn't it about time we all had our "duh" moment, and started adapting the technology to us?"
A classic: Eric Steven Raymond's The Cathedral and the Bazaar.
An interview with Ward Cunningham:
"I actually enjoy complexity that's empowering. If it challenges me, the complexity is very pleasant. But sometimes I must deal with complexity that's disempowering. The effort I invest to understand that complexity is tedious work. It doesn't add anything to my abilities.
A friend of mine once said that there are problems and there are difficulties. A problem is something you savor. You say, "Well that's an interesting problem. Let me think about that problem a while." You enjoy thinking about it, because when you find the solution to the problem, it's enlightening.
And then there are difficulties. Computers are famous for difficulties. A difficulty is just a blockage from progress. You have to try a lot of things. When you finally find what works, it doesn't tell you a thing. It won't be the same tomorrow. Getting the computer to work is so often dealing with difficulties.
The complexity that we despise is the complexity that leads to difficulty."
Data File Metaformats is a great chapter of Eric Steven Raymond's The Art of Unix Programming book.
It explains the history and pros and cons of text-based data file formats like CSV, RFC 822, XML, and INI.
Tim Bray: "There's a real interesting note from Campbell and Swigart lamenting the fact that, down in the coding trenches, the worlds of objects and of RDBMSes and of XML are far from unified, and that attempts in that direction have been less than enthralling. I think we just have to get used to it, and from here on in, the practice of software engineering is a three-legged discipline."
Eric Steven Raymond's The Art of Unix Programming book has a nice chapter summarizing the Basics of the Unix Philosophy...
Joel on Software: "When Unix was created and when it formed its cultural values, there were no end users. Computers were expensive, CPU time was expensive, and learning about computers meant learning how to program. It's no wonder that the culture which emerged valued things which are useful to other programmers. By contrast, Windows was created with one goal only: to sell as many copies as conceivable at a profit. Scrillions of copies. "A computer on every desktop and in every home" was the explicit goal of the team which created Windows, set its agenda and determined its core values. Ease of use for non-programmers was the only way to get on every desk and in every home and thus usability über alles became the cultural norm. Programmers, as an audience, were an extreme afterthought."
There's a nice comparison in the "Myths Open Source Developers Tell Ourselves" article:
"Think of your [software] project as your home. If you put things back when you're done with them, take out the trash every few days, and generally keep things in order, it's easy to tidy up before having friends over. If you rush around in the hours before your party, you'll end up stuffing things in drawers and closets. That may work in the short term, but eventually you'll need something you stashed away. Good luck."
Jon Udell: "Point-to-point integration is out; event-driven communication across a common message bus is in. When you build a system this way, message queues are the first and best way to take the pulse of its real-time state."
What's the right way to design/structure a Web Service? These two articles show the limitations of SOAP:
Hao He explains why SOAP is not SOA.
And Paul Prescod promotes REST... "[REST] applies the principles of the Web to transaction-oriented services, rather than publishing-oriented sites. When we apply the strategy in the real world, we do so using web technologies such as URIs, HTTP, and XML. Unlike the current generation of web services technologies, however, we make those three technologies central rather than peripheral -- we rethink our web service interface in terms of URIs, HTTP, and XML. It is this rethinking that takes our web services beyond the capabilities of the first generation technologies based on Remote Procedure Call APIs like SOAP-RPC."
Dion Almaer (focused on Java, but interesting nevertheless):
"This article discusses how caching data in front of the database can give our DB a break, and allow for faster running, and more available applications.
In particular, We will look at:
Alan Cooper tells how he invented the use of personas as a practical interaction design tool:
"[...] Even though the variation among the users was dramatic, a clear pattern emerged after just a few interviews. The users fell into three distinct groups, clearly differentiated by their goals, tasks, and skill levels. [...] So I created Chuck, Cynthia, and Rob. These three were the first true, Goal-Directed, personas.
Chuck was an analyst who used ready-built templates and reports. Cynthia was an analyst, too, and she used similar ready-built templates. But Cynthia also wrote her own templates, which she gave to Chuck to use. Rob was the IT manager who supported both Rob and Cynthia. He could optimize Cynthia’s templates, but he would never originate or use them.
At the next group meeting, I presented my designs from the points of view of Chuck, Cynthia, and Rob instead of from my own. The results were dramatic. While there was still resistance to this unfamiliar method, the programmers could clearly see the sense in my designs because they could identify with these hypothetical archetypes. From then on, I always presented design work using one of the personas, and eventually even the Sagent engineers began to talk about “what Cynthia would do” or “whether Chuck could understand” some dialog box."
Responding to Joel's essay, Ned Batchelder explains why exceptions do make sense: "Broadly speaking: * A-layer generates exceptions, * B-layer can often ignore the whole issue, and * C-layer decides what to do". I see.
Chris DiBona has a nice idea on SQL result caching: "First thing, before any actual real queries happen, the page construction logic should query the tracking table to get a list of tables that have become dirty since the last time a page was constructed, this can commonly become the only query that a page might see. In the event that a list of "dirtied" tables has been returned, the routine should remove the cached tables from whatever storage you're using."
In his Architecture Briefings, Ingo Rammer writes about many software developer's dislike of asynchronous processes:
The Flowchart Lie [PDF]: "It seems to be the common approach to map business processes to technical functions using general request/response style communication between client and servers. This is done even though most of the underlying business processes are inherently asynchronous and would therefore easily lend themselves a mapping to asynchronous messaging. [...] In practice, this simply leads to the the well-known "I'm really sorry. Please give me a second. Our computer system is very slow today" response on the phone."
SOAP is Not a Remote Procedure Call [PDF]: "It is for example quite unlikely that Amazon.com would allow your incoming XML Order message direct, real time access to its backend systems. It will instead store them in some sort of message queue so that it can process these messages whenever capacity is available, and will send outgoing OrderAccepted message later on."
Tim Bray On the Goodness of Unicode:
I always wondered what's so great about exceptions, and was glad that I don't have to use them while coding PHP... Now Joel explains why he doesn't like them:
"I consider exceptions to be no better than "goto's", considered harmful since the 1960s, in that they create an abrupt jump from one point of code to another. In fact they are significantly worse than goto's:
Mark Sigal: "When do client applications matter? Simply put, when does a rich client have an "unfair advantage" over a web browser in terms of bringing real value-add to the application composite?"
An ancient classic - I've got to re-read it from time to time: The Unix Philosophy book by Mike Gancarz is nicely summarized by David Calvert and Christian Weisgerber (the latter being written in German).
Eric M. Burke and his readers discuss Microsoft Word versus Wiki software for the purposes of project documentation: "I believe tools like TWiki offer an excellent alternative to Word documents for many kinds of documentation."
Tim Berners-Lee lists his principles of good design: "Again and again we fall back on the folklore of the principles of good design. Sometimes I need a URI for them so this is started as collection of them. I have written about some in many places. Principles such as simplicity and modularity are the stuff of software engineering; decentralization and tolerance are the life and breath of Internet."
In his Alertbox, Jakob Nielsen lays out his visions on software development:
"Just as Francis Fukuyama was wrong in predicting "the end of history," it would be wrong to predict the end of IT innovation. We still need some new features; hopefully they'll emerge more slowly than in the past, and be more solidly designed and implemented before they're unleashed."
"Computers are amazingly, remarkably, unbelievably fast. When you're executing compiled code that's running around structures in memory (and they actually fit in memory), you can do stupendous quantities of computation with no perceptible delay.
It's easy to forget that now; there are so many layers of database and application server and virtual machine and interface abstraction and method dispatching getting between our code and the metal that we often convince ourselves that the machines are slow. They're not; and when you need something to run really really fast, you can always make that happen, if you can push the problem down to traversing in-memory data structures with compiled code.
Of course, often you can't. This way of thinking about things is currently unfashionable, and in modern programming environments sometimes effectively impossible. But sometimes you need to do what seems impossible, and this is one way."
Jon Udell: "Software should recognize our patterns and make our lives easier."
ONLamp.com: "One of XP's catchphrases is "Do the Simplest Thing That Could Possibly Work." Solve the problem as simply as possible to get the job done correctly. Don't spend time creating a generalized solution (or worse, a generalized framework) if you don't need it yet."
Jon Udell doing advocacy for Test-driven development...
Ward Cunningham citation: "When somebody says this is test-first code, you believe that it's going to be more robust than otherwise. And if you do run into a limitation, it's more likely that you can get past it. Test-first means that it's clear what the code does, and that what it does has been tested, but also that the code doesn't devote a lot of effort to doing things that aren't declared."
Roger L. Costello: "Here are the characteristics of REST:
Richard P. Gabriel: "The concept known as “worse is better” holds that in software making (and perhaps in other arenas as well) it is better to start with a minimal creation and grow it as needed. Christopher Alexander might call this “piecemeal growth.” This is the story of the evolution of that concept."
Daniel Smith's report on "PortLAMP Courses: Monday", including a nice overview of Sterling Hughes' talk on Advanced PHP, and some Jabber comments:
"[Jabber] is also good at detecting the presence of people AND machines (think of a buddy list for an app that can open a connection to a Jabber server, or to you personally)"
