12 Aug

Paul Graham – What Happened to Yahoo

So which companies need to have a hacker-centric culture? Which companies are “in the software business” in this respect? As Yahoo discovered, the area covered by this rule is bigger than most people realize. The answer is: any company that needs to have good software.

Why would great programmers want to work for a company that didn’t have a hacker-centric culture, as long as there were others that did? I can imagine two reasons: if they were paid a huge amount, or if the domain was interesting and none of the companies in it were hacker-centric. Otherwise you can’t attract good programmers to work in a suit-centric culture. And without good programmers you won’t get good software, no matter how many people you put on a task, or how many procedures you establish to ensure “quality.”

Hacker culture often seems kind of irresponsible. That’s why people proposing to destroy it use phrases like “adult supervision.” That was the phrase they used at Yahoo. But there are worse things than seeming irresponsible. Losing, for example.

via Paul Graham – What Happened to Yahoo. Paul Graham discusses the issues surrounding building and maintaining a hacker culture.

04 Aug

Drawar – Design The Experience: Expectations

Price isn’t always the first impression that one gets from an experience, but it is a key component on how expectations can be set for a person. A couple of weeks ago I flew Midwest Airlines and I didn’t know anything about them. They had the cheapest price flight so I went with them. Upon arriving at the terminal I saw they had different seats than Southwest which was right across the aisle. Their seats sucked and were uncomfortable. I always figured that all airlines had the same seats, but Southwest had lounge chairs that looked like you could sit down in them all day. Midwest had seats built for a three-year old.

via Drawar – Design The Experience: Expectations. If you set up your site for a bad expectation, the customer gets a bad experience.

02 Aug

52 Weeks of UX – The Five W’s of UX

Who, What, Where, When, Why (and How – it ends with a “w” cut me some slack). In school we were taught that these fundamental questions must be addressed in the process of creating a strong argument and delivering a legitimate story. In the world of User Experience, being able to accurately answer these 5 questions can be the difference between a product that instantly resonates with the customer and one that quickly makes its’ way to the Startup Graveyard.

via 52 Weeks of UX – The Five W’s of UX. Important questions for any business to keep at the fore front of any existing or new products.

02 Aug

The New Yorker – WikiLeaks and the war in Afghanistan

Almost immediately, a consensus emerged that little in the files was actually secret or new. There is something to that. We did know, in a general sense, much of what they document: that the regime of President Hamid Karzai is corrupt and unpopular, that Pakistan’s Inter-Services Intelligence agency has ties to the Taliban, that too many civilians are dying. There had been reports, including some in this magazine, of targeted killings. And we knew that the Afghan security forces were a disaster, even after we had spent twenty-seven billion dollars to train them. But knowing specifically what happened to a sixteen-year-old girl and to the man who stood up to her alleged rapist—and knowing that her attacker may have been in a position to do what he did because he was backed by our troops and our money—is different.

via The New Yorker – WikiLeaks and the war in Afghanistan. More analysis into the WikiLeaks release of documents regarding the Afghanistan war.

02 Aug

NYTimes.com – Defining Prosperity Down

The point is that a large part of Congress — large enough to block any action on jobs — cares a lot about taxes on the richest 1 percent of the population, but very little about the plight of Americans who can’t find work.

via NYTimes.com – Defining Prosperity Down. Krugman once again with arguing forcefully and eloquently for some rational decision making on the part of economic policy.

01 Aug

The New Yorker – Filibusters and arcane obstructions in the Senate

The weakened institution could no longer withstand pressures from outside its walls; as money and cameras rushed in, independent minds fell more and more in line with the partisans. Rough parity between the two parties meant that every election had the potential to make or break a majority, crushing the incentive to coöperate across the aisle. The Senate, no longer a fount of ideas, became a backwater of the U.S. government. During the Clinton years, the main action was between the White House and the Gingrich House of Representatives; during the Bush years, the Republican Senate majority abdicated the oversight role that could have placed a vital check on executive power.

via The New Yorker – Filibusters and arcane obstructions in the Senate. Lot of interesting analysis behind why the Senate out of all the bits and pieces of government is weirder and more prone to hindering government rather than actually governing.

01 Aug

Review/Summary of The Mythical Man Month

The Mythical Man Month is one of those seminal works of software engineering that praise is heaped upon and quoted at most if not all software firms. The book itself is perhaps most famous for popularizing the rule that “adding more programmers to a late project makes it even later”. This however is not the only conclusion to be gathered from this book.

The Summary

The book should perhaps be most praised for being written in a manner that the engineer in me can get behind. Short and fast chapters with not a lot of fuss of double telling a point after it has been made. Including a bullet point review of the book, it is a short 300ish pages long. Perhaps the largest complaint of the book is that the focus of the book is upon system or what is now known as embedded programming. That being said there are a great many points to be gathered from the book.

The first is that there are several different types of programs, simply a program, a programming system, a programming product and finally a programming system product. Only the last is one that is the goal of most programming teams. The first is essentially something that the programmer can use and build in the course of a few days or weeks of effort. The second and third are required intermediaries to the fourth but moving in opposite directions. A programming system is where a program becomes a part of a larger project. This requires the program to mandate all input and output to be semantically valid and correct, to be on a well-defined budget of resources (be they computer time/memory and i-o limitations) and to play well with other program.

The programming product requires a vast suite of test cases so that other programmers may rely upon it and through documentation so that others may extend it’s feature set. Each of these two intermediary steps requires in the authors words “three times the cost of the earlier one”, so that together the programming system product “costs nine times as much”.

Still inside of the first chapter, do we get the next great revelation; programming is a fun and abstract art. This leads to its own set of problems, least of which is the abstract part. Perhaps the greatest of these is the requirement of perfection demanded from computers. The list of problems quickly grows in the next few paragraphs, being at the whim of others decisions and others goals, depending upon others perfection for a programmer rarely works alone in all aspects of a project, the design is more fun that actual implementation, debugging becomes more difficult the further one goes, and finally that rarely does it seem to be ahead of the curve more often than not it feels that the project is already obsolete before completion.

I love the image that the author weaves here of Software Engineering being a tar pit and him trying to “lay some boardwalks across the tar”.

Scheduling software is a notoriously dark art. The author brings forth a simple and basic rule for dividing up the time on a software project.

  • 1/3 Planning
  • 1/6 Coding
  • 1/4 Component and early system test
  • 1/4 Systems test, all components in hand

The next bit is the most famous of the conclusions from the book in which the author discusses how adding more people to a project doesn’t make it any sooner to completion, if anything slows down the project overall. There is the matter of both training these new engineers on the inner workings of the project before they can even be brought into working on the project on anything approaching a full-time basis, the next is that as you add more people there develop more lines of communication and more time to delegate and split tasks into manageable pieces for each person to work on. Essentially far easier for two people to meet and decide on two parts of the project to tackle, far harder for three, four or five people to meet and delegate the project into x number of pieces for each to work. Especially for the task to be divided in such a way that you are both accounting for one’s abilities and trying to time the project so each finishes at roughly the same time.

The author coming from the discussion of how more people on a project leads to an overall slowdown in the project argues with more data than any other section for a “surgical team” to tackle projects, even those ridiculously large ones to be split into manageable portions for surgical teams to take on as opposed to “hog-butchering team”. Essentially for a coordinated effort by one or two programmers with all others acting in support of those one or two programmers.

The vast majority of the rest of the book espouses and stresses these points in some way or another. From espousing that a good design (note design here terms of design of the architecture not design in look and feel) can only come from a single or extremely limited number of persons. That architects of systems of a system have a tendency to over design to achieve complete interoperability and extensibility. Assigning value to both the number of bytes and time needed for a function to complete is a good way to limit over design.

There must be both formal and informal level design documentation. Intercommunication and organization are requirements for even a decent project to take flight not just among team members but across all teams. The author argues for daily meetings for all team members with weekly inter-team meetings. He also argues for some form of a project workbook to collect all changes and thoughts of the team members so that anyone reviewing or testing a section has complete access to all knowledge of that section on the spot. At the same time the author argues for all team members being required to see and read the workbook, at a later date he becomes convinced otherwise and instead stresses that the information be made available but not in essence required reading. Plan for throwing away an initial version of the project. Iterate quickly on a project, create a working version as quickly as possible and keep up it’s working state throughout the course of the project. A project does not all of sudden become late but rather over the course of one piece taking longer or one day of missed meetings.

Documentation while hated is a really important feature for a good project, not just for the customer but for programmers to know the why behind a piece of code. Re-using or purchasing that which has previously been done to save lots of time and effort than in effect re-creating the wheel. Adding functionality to software in a piece-meal fashion, rather than all at once.

It’s all in all a long list of points for such a short book and perhaps most interesting for being such an old book espouses some ideas that I would have thought not in practice until much later.

The Review

Overall wonderful to read, super fast and easy to read. Lots of examples and data points from basic research to analogues and one-off stories to provide force behind each point. The majority of the points I would take little to no time to critique except for that it focuses heavily on systems programming and hence not in an area that I find myself (and probably most modern programmers) working in. Little effort to none is made for focusing on the actual usability of a project beyond that of other programmers, whereas most Software Engineers find themselves writing code that a normal human being will interact and deal with. The book also develops a ten person strong team with just one or two people actually devoted to writing code. This seems more than a bit of overkill. I would suggest something much closer to the 37Signals plan, one manager, two programmers, one designer and one tester. Perhaps my smallest critiques is the focus on “man” hours as opposed to person hours, also the little one off here and there of using a religious idea as proof for a software engineering plan. For instance, in the bullet points on using two core programmers on a team the author makes a footnote of “Note God’s plan for marriage”. Minor annoyances I admit but they detract from an other wise well written and developed ideas.

I would recommend this book to not just Managers of software projects but also to the programmers under their leadership in the hope that they understand better the difficulty in creating an outstanding “programming system project” and quite possibly how to build a better maintainable project.

01 Aug

The New Yorker – The real numbers on illegal immigration

In fact those numbers are surprising: they are sharply down, according to the Border Patrol—by more than sixty per cent since 2000, to five hundred and fifty thousand apprehensions last year, the lowest figure in thirty-five years. Illegal immigration, although hard to measure, has clearly been declining. The southern border, far from being “unsecured,” is in better shape than it has been for years—better managed and less porous. It has been the beneficiary of security-budget increases since September 11th, which have helped slow the pace of illegal entries, if not as dramatically as the economic crash did. Violent crime, though rising in Mexico, has fallen this side of the border: in Southwestern border counties it has dropped more than thirty per cent in the past two decades. It’s down in Senator McCain’s Arizona. According to F.B.I. statistics, the four safest big cities in the United States—San Diego, Phoenix, El Paso, and Austin—are all in border states.

via The New Yorker – The real numbers on illegal immigration. The New Yorker does some slapping around of politicians who just outright lie in an effort to create fear.

01 Aug

Paul Graham – How to Start a Startup

You need three things to create a successful startup: to start with good people, to make something customers actually want, and to spend as little money as possible. Most startups that fail do it because they fail at one of these. A startup that does all three will probably succeed.

via Paul Graham – How to Start a Startup. An awesome essay on what it takes to create a technology business.

01 Aug

Ars Technica – Ballmer (and Microsoft) still doesn’t get the iPad

The message was clear: Microsoft still doesn’t understand why its Tablet PC concept has repeatedly bombed over the best part of a decade. Apple sold more iPads in its first three months of availability than PC vendors sold Tablet PCs in the whole of last year; in fact, the number of iPads sold in that period is likely to eclipse the number of Tablet PCs sold both last year and this. But still the company is persevering: stick a regular PC operating system on a laptop, give it a touchscreen, and then take away the keyboard and pixel-perfect pointing device. Ballmer even reiterated the company’s position: slates are just another PC form factor.

via Ars Technica – Ballmer (and Microsoft) still doesn’t get the iPad. Yet another in the long story of why Apple wins in this market and Microsoft fails. The iPad isn’t just a computer scaled down. It’s not a scaled down version of Mac OSX either. The iPhone runs a flavor of Mac OSX that has been customized to fit the hardware. The iPad is more of a scaled up version of this rather than a scaled down version of the full Snow Leopard. This lends two things:

  1. Touch works beautifully since touch is a first class interface on the iPhone.
  2. Doing one thing at a time is already perfected, great for an overall slower and smaller machine than a normal laptop (ie. closer to a netbook or slate as Steve Ballmer calls them).