LINK: HTML5 Is Dead. Long Live HTML5!

As a fellow HTML evangelist myself since the first day I developed a website, I fully feel Zuckerburg’s sentiments on HTML5 over native apps. I guess everything old is new again though, and the general public demanded a better (faster) user interface for many things than the current generation of mobile internet bandwidth and smartphone web browser could provide, and found those in native apps for their phones. I think the biggest thing Zuckerburg is really saying here, though, is that they were trying hard to not have complete forks of their codebase, and in the end, they decided they had to.

LINK: Build a Private Social Network that Employees Will Actually Use

LINK: New Analyst Report Rips Agile: Says It’s ‘Designed to Sell Services,’ a ‘Developer Rebellion Against Unwanted Tasks’

In my opinion, it’s a developer’s ability to comment his or her code effectively that really separates quality programmers from someone who can just get things to work somehow. There’s always more than one one way to code a process, and a developer’s code comments should make some attempts to explain the choices made and the logic the code is trying to follow. Beyond that, variable names, function names, database tables, etc. should all have meaningful names, too, so there should be a level of documentation in the code just by being a good programmer, regardless of the methods used for project management. Code comments and meaningful variable / function / table names are valuable not only to the programmers while writing and maintaining their own code, but for anyone who gets added to the project later or has to maintain it. That being said, software development is unbelievably tedious and complex since you can write thousands or millions of lines of code and a simple comma or quotation mark in the wrong place will bring the whole thing to a screeching halt. Things have to be documented in writing, in charts, and/or in process diagrams, because verbal agreement only gets you so far — people fall sick, get pulled off on other projects, etc. One of the most limiting factors in software development scaling is communication, and if all your communication is verbal, then an experienced programmer will always be on the other side of that conversation, and experienced programmers are hard to get a free moment with. Agile is a little bit like Bigfoot for me, though — I’ve heard enough about it to think it exists somewhere, but I haven’t actually seen it yet. You need to test early and often, but this can wear out some clients fast — often much faster than the developers — and the simplistic nature of the first tests can often cause client heartburn because their first glimpse of the project is often something basic that doesn’t work, so it plays on their fears that they’re going to burn through all their cash and all they’ll ever get is something that is simple, expensive, and doesn’t work. First impressions matter! This can hurt developers the other way as well, because if your initial tests succeed, the client might think the code is basically ready when you’re not even 20% of the way through the project and then when you’re 40% of the way through the project, the client feels like the project should be done tomorrow. However, the 80/20 rule applies here and the last 20% of the details will take 80% of the time to finish. What that really means is that for more than 70% of the project, the client ends up thinking, “We’re almost done!” and then they start thinking that the developers are really milking them for all they’re worth because the initial tests went well and did NEARLY everything they desired. So developers end up with clients who vacillate between “this thing is always gonna suck” and “these people are taking me for all I’m worth”. This is the crux of the problem — if you’re working on a fixed bid for the project, it’s hard to be agile, and if you’re working on some sort of hourly rate, the client thinks they’re always going to get screwed and I think what ends up happening many times is the projects end up getting cut short before the final touches are on the project, like good end user documentation, simply because the client is exhausted and doesn’t want to continue. A construction project building a building might look like a mess up until the last moment, but at least the client can go stand in the middle of it (it’s a physical place) and everyone has seen a bunch of buildings built that they had no intimate involvement in, so they almost intuitively KNOW it’s going to be a mess up until the end. But a software project may be more like asking a client to participate in an emergency open heart surgery on someone you’re in love with (clients love their businesses) because most people would be so freaked out 5 minutes into surgery, they couldn’t stand to watch even while the best heart surgeons in the word operate because all they would be thinking is that their loved one is either going to die or be maimed for life, regardless of any assurances from the surgeon that everything will be OK in the end.

LINK: The Care and Feeding of Software Engineers (Or, Why Engineers Are Grumpy)

This is one of the best articles on developer culture I’ve read — required reading for anyone who is a developer/programmer as well as anyone who has any professional interaction with them.

To understand the problem, consider the job of building a house. Someone has decided they want to build a house on a specific plot of land. The house is to be two stories and have a garage. There’s even a rough sketch of the front of the house scribbled down on a napkin. That person comes to you with this information and the napkin and says, “this is enough for you to start building, right?” Are you able to start building?

Logically, you can’t start building the house at that point. You don’t know the square footage. You don’t have floor plans. You don’t know what sort of codes the city requires for new houses. There’s literally not enough information for you to even start digging up dirt. At this point, you’d tell your customer that they are crazy and need to figure out exactly what they want. Now imagine you can’t do that, because there’s a deadline that someone set and you’re responsible for meeting.

“Well,” your customer tells you, “why don’t you just start building, and I’ll get you the details as they become available. That way, we’re not wasting any time.”

You know that there’s not enough information for you to start building, and further questioning the customer won’t yield any additional information right now. Yet, you have a deadline to meet and so you really can’t afford to sit around and wait for more information. What do you do? You start making assumptions.

After a week of working on the garage, your customer emerges with more details. In fact, the house has to be three floors (phew, good thing you didn’t start there) and will have eight bathrooms. There’s no further information about the garage, but the house is going to be painted blue. You then logically assume that the detached garage should also be painted blue and so that’s where you spend time next.

A few days later, the garage is almost done. You feel pretty happy about the quality because you went on so little information. You’re now ready to start on the house when your customer comes back with more details. The garage actually needs to fit two cars and should not be detached. Your heart sinks, since you had created something nice and now it needs to be bulldozed to make way for the “real” thing. What’s worse, you now have less time to complete the entire project, which only increases the grumpiness level.