The term "technical debt" was coined by Ward Cunningham to describe the obligation that a software organization incurs when it chooses a design or construction approach that's expedient in the short term but that increases complexity and is more costly in the long term.
..
What is Technical Debt? Two Basic Kinds
The first kind of technical debt is the kind that is incurred unintentionally. For example, a design approach just turns out to be error-prone or a junior programmer just writes bad code. This technical debt is the non-strategic result of doing a poor job. In some cases, this kind of debt can be incurred unknowingly, for example, your company might acquire a company that has accumulated significant technical debt that you don't identify until after the acquisition. Sometimes, ironically, this debt can be created when a team stumbles in its efforts to rewrite a debt-laden platform and inadvertently creates more debt. We'll call this general category of debt Type I.

The second kind of technical debt is the kind that is incurred intentionally. This commonly occurs when an organization makes a conscious decision to optimize for the present rather than for the future. "If we don't get this release done on time, there won't be a next release" is a common refrain—and often a compelling one. This leads to decisions like, "We don't have time to reconcile these two databases, so we'll write some glue code that keeps them synchronized for now and reconcile them after we ship." Or "We have some code written by a contractor that doesn't follow our coding standards; we'll clean that up later." Or "We didn't have time to write all the unit tests for the code we wrote the last 2 months of the project. We'll right those tests after the release." (We'll call this Type II.)

The Cofundos process itself is schematically depicted in the figure and works as follows:
Somebody misses an open-source software tool or library for a specific purpose, a feature in an open-source software or a plugin for an existing software. He describes the project to develop the software.
Requirements-Engineering: Other people help enhancing the description of the project by adding specific requirements and comments.
Bidding: Users who also like the project and need the resulting software, bid a certain amount of money, which they will donate to the project performer after its successful completion.
Offering: Specialists who are capable to perform the project and to develop the respective software offer to realise the project for a certain amount of money and within a certain timeframe.
Call for competitive offers: As soon as the sum of the bid amount exceeds the money requested by the first offer, a call for competitive offers is started and lasts for three week.
Accepting an offer: After the three weeks call period for alternative offers is elapsed, all bidders are requested to vote about which offer to choose. Bidders votes are weighted by the amount of their bid. The specialist with the majority of the votes is selected to carry out the project.
Voting about project success: After the specialist announces the completion of the project or the development timeframe as suggested by the specialist elapsed, the bidders vote about how the initially defined requirements (agreed on by the specialist) are met by the provided solution.
Donation to the specialist carrying out the project: If the majority of the bidders agree that the requirements are met, bidders are requested to make the respective donations.
If the majority of the bidders decide that the requirements are only partially met by the implementation, an extension will be granted to the specialist for improving his implementation.
If the majority of the bidders decide that the requirements are not met by the implementation, the project failed, no donations will be made and the project might be reopened for bidding.

I spent two years trying to make Rails do something it wasn’t meant to do, then realized my old abandoned language (PHP, in my case) would do just fine if approached with my new Rails-gained wisdom.

...Programming changes the way you think...
Programming presents you with a problem and allows you to eventually solve it provided you don’t quit. A solution is out there somewhere. Make enough attempts and chances are you’ll eventually prevail. Aren’t computers great? They afford a large degree of freedom in problem solving. If nothing else, you are able to make as may attempts as you please and it will happily execute each one. This instills in you a sense that failure is not final. Any obstacle can be hurdled. This is not true in the real world. While you may find second chances now and again, the wheels that turn in the big blue room are largely unforgiving. Time marches on in one direction.

When faced with an interesting programming problem your mind will chew it over in the background. Maybe it’s an algorithm you need to develop, maybe it’s a tricky architecture problem, maybe it’s data that needs to be modeled. It doesn’t matter. Your mind will quietly work the problem over in search of a solution. The “ah-ha!” moment will come when you’re in the shower, or playing Tetris. This practice of constant churning will slowly work its way into the rest of your life. Each problem or puzzle you encounter will start it’s own thread; the toughest and most troubling of which will be blocking...

A good programming language is far more than a simple collection of features. My ideal is to provide a set of facilities that smoothly work together to support design and programming styles of a generality beyond my imagination. Here, I briefly outline rules of thumb (guidelines, principles) that are being applied in the design of C++0x. Then, I present the state of the standards process (we are aiming for C++09) and give examples of a few of the proposals such as concepts, generalized initialization, being considered in the ISO C++ standards committee. Since there are far more proposals than could be presented in an hour, I'll take questions.

Have an idea? Just need funding?
Want to join with others to support to an idea?
This site is for you.

FEES:
License fee:
Open source license: Free.
Closed source license: 3% of each progress payment.
Proprietary license: 6% of each progress payment.
Quitting a project early: 10% of your earnings so far; microPledge will pledge the fee to the project so it can be earned by any subsequent developer.
Refunds. Unless you are doing open source, you must refund all your earnings back to pledgers if you don’t finish the project. Either that or you must release your source.
Upload cap: for project releases above 10MB, $0.20 per MB in excess.
Incubator: $20 basic fee. Challenges cost $60 per hour of arbitration after the first hour.

VanFossen isn't referring to the kind of plagiarism in which a lazy college student copies sections of a book or another paper. This is automated digital plagiarism in which software bots can copy thousands of blog posts per hour and publish them verbatim onto Web sites on which contextual ads next to them can generate money for the site owner.

Such Web sites are known among Web publishers as "scraper sites" because they effectively scrape the content off blogs, usually through RSS (Really Simple Syndication) and other feeds on which those blogs are sent.
...
"It wasn't the issue of money," Leder added. "When other people's business model is based on stealing content, that's a significant problem."

Angle Brackets and Curly Braces
Programming with "Duh" Typing
by Bill Venners
July 6, 2007

    Summary
    To what extent does the productivity of dynamic languages come from the lack of typed variables versus the reduction in "finger typing" required when you don't have to declare the types? The technique of type inferencing in static languages may shed new light on this old debate.

Over the years here at Artima we've had a number of debates and discussions about static versus dynamic typing. Here are a few:

    * Are Dynamic Languages Going to Replace Static Languages?, discussion of a weblog post by Robert C. Martin.
    * Typing: Strong vs. Weak, Static vs. Dynamic, discussion of a weblog post by Aahz.
    * Strong versus Weak Typing, discussion of an interview with Python's creator Guido van Rossum.
    * Implicit versus Explicit Dynamic Typing, discussion of a weblog post by Christopher Diggins.
    * To type or not to type, discussion of a weblog post by Jim Waldo,
    * Use the Best Tool for the Job, discussion of a short article by a younger me.

...Any child of the 1980s and 1990s will remember Mavis Beacon Teaches Typing and Math Blaster Mystery: The Great Brain Robbery, games that promised to make skills acquisition fun. They'll also remember ditching Mavis Beacon for something with guns as soon as their parents' backs were turned. Making games educational is like dumping Velveeta on broccoli...

...This paper examines several approaches to which programming language is the best, and afterwards gives several useful relations for which languages should come first. Finally it gives a final verdict, defends it and then gives some other good food for thought...

The most common is to grant patents that shouldn't be granted. To be patentable, an invention has to be more than new. It also has to be non-obvious. And this, especially, is where the USPTO has been dropping the ball. Slashdot has an icon that expresses the problem vividly: a knife and fork with the words "patent pending" superimposed.

The scary thing is, this is the only icon they have for patent stories. Slashdot readers now take it for granted that a story about a patent will be about a bogus patent. That's how bad the problem has become.

The problem with Amazon's notorious one-click patent, for example, is not that it's a software patent, but that it's obvious. Any online store that kept people's shipping addresses would have implemented this. The reason Amazon did it first was not that they were especially smart, but because they were one of the earliest sites with enough clout to force customers to log in before they could buy something. [1]

We, as hackers, know the USPTO is letting people patent the knives and forks of our world. The problem is, the USPTO are not hackers. They're probably good at judging new inventions for casting steel or grinding lenses, but they don't understand software yet.

The Hacknot Book
"Hacknot: Essays on Software Development" contains 46 essays, each of which was originally published on this site between July 2003 and October 2006. Soft copies of the book may be downloaded for free.
The book is available in two formats - Novel and A4. If you are printing the PDF yourself...

Presented, in no particular order, for your reading pleasure: my top 6 list of programming top 10 lists. To keep this entry concise, I've only quoted a brief summary of each item. If any of these sound interesting to you, I encourage you to click through and read the original author's thoughts in more detail.

The fifteen Commandments of Good Programming.
The following are the fifteen commandments of good programming. They are an imperative to having a smooth time after initial deployment of your program at the customer’s site. Follow these steps and you will have much lesser work maintaining the software that you have made.

To summarize some of my earlier thoughts, most games have scores which indicate relative success to other players, as well as relative success to our own previous scores. Yet, at the end of most games, we discard these scores and simply assign a "1" (for win) or a "0" (for loss) to all participants.
Or More Specifically
My goal is to separate "winning" from "goals" and "competition". Consider a game of Chess.
In the game of Chess, the goal is to checkmate your opponent. The game is competitive, in that one player works to thwart the other from doing so. The game is designed to end as soon as one player achieves their goal, thus preventing the other player from achieving theirs.

The goal of the study on Fun and Software Development (FASD) is to precisely assess the importance that fun has as motivation for software developers to engage in open source projects. A survey carried out both under open source developers and programmers working in Swiss software companies yielded that the fun motive accounts for about 27 percent to 33 percent of open source developers’ motivation.
Fun is a pervasive feature of software development, not only for open source programmers but in the area of commercial software development too: Open source developers that are paid for their work are observed to be very motivated and prepared for future effort, especially if they enjoy their development time. Furthermore, the fun that programmers experience functions as a good proxy for their productivity. Therefore, employers that want to enhance the programmers’ productivity can safely invest in an environment of fun for developers in their company.

Several of Bruce Tate’s books focused on the flaws in Java and the need to let go of some of the ideas that haven’t worked out. And blogs like this and this have been appearing more frequently. And of course there’s Steve Jobs now-famous quote (referring to the iPhone): “Java’s not worth building in. Nobody uses Java anymore. It’s this big heavyweight ball and chain.”
This backlash has only been necessary because of Sun’s death grip on the idea of ubiquitous, omniscient Java. It was admirable once, but a language only evolves if its designers and advocates can acknowledge problems. Pretending that a language is successful in places where it’s not is just denial.
Some adaptations have occurred. Finally admitting that EJBs have cost the world enormously, the EJB3 team...

One way to look at Salon co-founder Scott Rosenberg's new book, "Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software," is as an attempt to tell the story of a specific software development project -- the effort by industry legend Mitch Kapor and a band of ace programmers to create Chandler, a kind of turbo-powered personal information management program that would dazzle users with its ability to enhance their productivity...

As promised, here's my 25 steps for building a Micro-ISV which are hard learned steps based on our experience getting TimeSnapper to where it is today. Each of these steps is both harder than it looks, and easier than you'd think.

It's hard because there are pitfalls, procrastination, miconceptions, anxiety, conflicting opinions and confusion at every step. It's easy because, hey, you're a smart guy or gal, so you can do this stuff in your sleep.

In defense of simplicity
Recently two notable design advocates, Don Norman and Joel Spolsky, challenged the value of simplicity in design, and I’m here to offer a late defense.
...
It’s easy to confuse success with quality, and both articles discount our secret inability to make satisfying choices. We are attracted to things with more features, that cost less, or come in larger quantities, despite our inner suspicions that we’re likely to complain about those purchases soon after. We date people, eat food, take jobs and buy products for superficial, misguided reasons all the time. We’re easily seduced, and every marketer knows we always have been and always will be.

But we shouldn’t confuse the success of feature-laden crap as a signal for the irrelevance of simplicity any more than the success of Rocky IV and Burger King signaled the irrelevance of good film-making or fine dining. It just means there are gaps between what we need, what we want, and why we buy, and that the masses are by definition less discriminating than the niches of people with refined tastes for a particular thing.