Here is late-breaking news about programming languages. The newest, spiffiest, got-to-have-it language is out. It's called LOLcode.
The name comes from the internet LOLcats, since the language is based on their dialect of English. To my knowledge, this is the only programming language based on English since COBOL.
Here is a sample program:
HAI
VISIBLE "I can has cheezburger?"
I HAS A VAR ITZ 1
VISIBLE "I do count!"
IM IN YR LOOP
VISIBLE VAR
IZ VAR BIGGER THAN 19 O RLY?
YA RLY
GTFO
NO WAI
UP VAR!!1
KTHX
KTHX
KTHXBYE
Like COBOL, all keywords and variable names are in uppercase. And like COBOL, it is meant to be 'readable'. Unlike COBOL, it is meant to be readable by today's up-and-coming internet-savvy, text-phone-using teens, the programmers of tomorrow.
This just may be the next big thing for programming.
Remember, you saw it here first!
Sunday, October 28, 2007
Sunday, October 14, 2007
Heresy 1: Agile is not fast
It may be a heresy, but I will state it:
Agile Development is not faster than waterfall development.
Programmers using Agile techniques are not faster at adding functionality (or requirements, or function points, or any metric you care to use) than developers using waterfall project planning.
As I see it, Agile techniques offer two advantages: consistent levels of quality and the ability to change you mind. With Agile techniques, the 'test before code' practice ensures that you have tests in place and that all new features work, without breaking existing features. The close contact with users and small steps in development (avoiding the large, "think of everything at once and in the beginning" plans of waterfall) lets you decide on the features to add late in development.
Waterfall makes you commit to functionality up front. Typically, the development organization asks the user organization for a list of changes (in order of priority), estimates the effort for each item, estimates available capacity, and then negotiates on the list of items for the release. This list becomes "the commitment" which is then judiciously guarded by the development organization against changes from the user community.
Agile lets you defer "the commitment" and in fact breaks it down into smaller commitments, usually every week or two. The user community can think about new features and postpone the decision to add them. Rather than one big list decided up front, the list starts small and then adds items in small spurts.
But I see nothing in development practices that make developers go faster. (Well, there are benefits from the test-driven practices, but a waterfall-planned project could use test-driven practices for adding features, so there is nothing unique to Agile.) Programmers add code (features, requirements, function points, what-have-you) at the same rate as development.
I believe that Agile Development is perceived as faster than most waterfall projects, from the effects of test-driven development and the ability to change feature sets. I believe that many users are frustrated with the "committed feature set" of waterfall development (probably the day after the commitment) and welcome the time-delayed possibilities of Agile.
But in the end, the number of features added will be about the same.
So it is not actual performance, but perceived performance that makes Agile development seem faster.
Agile Development is not faster than waterfall development.
Programmers using Agile techniques are not faster at adding functionality (or requirements, or function points, or any metric you care to use) than developers using waterfall project planning.
As I see it, Agile techniques offer two advantages: consistent levels of quality and the ability to change you mind. With Agile techniques, the 'test before code' practice ensures that you have tests in place and that all new features work, without breaking existing features. The close contact with users and small steps in development (avoiding the large, "think of everything at once and in the beginning" plans of waterfall) lets you decide on the features to add late in development.
Waterfall makes you commit to functionality up front. Typically, the development organization asks the user organization for a list of changes (in order of priority), estimates the effort for each item, estimates available capacity, and then negotiates on the list of items for the release. This list becomes "the commitment" which is then judiciously guarded by the development organization against changes from the user community.
Agile lets you defer "the commitment" and in fact breaks it down into smaller commitments, usually every week or two. The user community can think about new features and postpone the decision to add them. Rather than one big list decided up front, the list starts small and then adds items in small spurts.
But I see nothing in development practices that make developers go faster. (Well, there are benefits from the test-driven practices, but a waterfall-planned project could use test-driven practices for adding features, so there is nothing unique to Agile.) Programmers add code (features, requirements, function points, what-have-you) at the same rate as development.
I believe that Agile Development is perceived as faster than most waterfall projects, from the effects of test-driven development and the ability to change feature sets. I believe that many users are frustrated with the "committed feature set" of waterfall development (probably the day after the commitment) and welcome the time-delayed possibilities of Agile.
But in the end, the number of features added will be about the same.
So it is not actual performance, but perceived performance that makes Agile development seem faster.
Wednesday, October 3, 2007
What Techies want
Techies are not so hard to understand. Their wants are simple. Christine Comaford, back in the 1980s, listed four things that techies want:
1) Lavish praise
2) Fun projects to work on and fun tools to work with
3) Free beer and pizza
4) Some money
I liked this list so much I stole it. I repeat it when I can (always giving Ms. Comaford-Lynch credit).
I also modified this list. My modified version is:
1) Lavish, genuine praise
2) Fun projects to work on and fun tools to work with
3) Free beer and pizza, although perhaps not for dinner every night
4) Some money
People (non-techie people, that is) are surprised at the position of money. And at the qualifier "some". Techies don't want lots and lots of money. In general, they want enough to live in reasonable quarters, pay for things like food and the phone bill, and have enough left over for books, music, games, and a few other vices.
It's not that hard.
1) Lavish praise
2) Fun projects to work on and fun tools to work with
3) Free beer and pizza
4) Some money
I liked this list so much I stole it. I repeat it when I can (always giving Ms. Comaford-Lynch credit).
I also modified this list. My modified version is:
1) Lavish, genuine praise
2) Fun projects to work on and fun tools to work with
3) Free beer and pizza, although perhaps not for dinner every night
4) Some money
People (non-techie people, that is) are surprised at the position of money. And at the qualifier "some". Techies don't want lots and lots of money. In general, they want enough to live in reasonable quarters, pay for things like food and the phone bill, and have enough left over for books, music, games, and a few other vices.
It's not that hard.
Subscribe to:
Posts (Atom)