Eliminating Web Development Waste | Hacker News Reader

Eliminating Web Development Waste

nefariousdesigns.co.uk

34 pointsIsofarro12 comments

"The most common delays in web development are when work passes between individuals."

Especially when it's completely unnecessary. Some of my recent work has taken longer than it should b/c I'm having to debug my work through my supervisor. By through, I mean that he insists on watching the error logs on a remote server for me, and then telling me what the error is, and then I can adjust my code. My request to gain access to the entire stack so that I can debug my work on my own was met with defensive arguments.

"This has been described by Douglas Crockford—the inventor of JSON..."

He didn't invent it.

Source: Douglas Crockford @ 0:55 - 1:10 in this video: http://www.youtube.com/watch?v=kc8BAR7SHJI

Not giving a developer direct access to error reports for the code you are working on sounds like one of the biggest inefficiencies I have ever heard of.

In some situations, giving developers direct access to remote [production] servers is unacceptable. (Areas like healthcare, banking.)

Not everything in life is about developer efficiency.

Couldn't you have it log to some div on the homepage? Then you wouldn't have to go through your boss.

The error logs I was referring to are on the other side of an API, and the error response isn't being returned to the client in any way. But I get your point, there should be better, faster ways to debug, like:

a) return the error messages, even if only in dev environments

b) convince my supervisor that I should have access to the shared api server

c) run the entire app stack in a local dev environment (which I prefer the most)

We're making progress on all those now, but only after a round or 2 of push back from my supervisor.

Just quit. It ain't worth it.

Though those in C-level and sales-focused positions do not always understand the need, every project I have ever worked on has benefited greatly from a thorough pre-production process.

It is the ready-shoot-aim projects that are the greatest victims of these issues, even though we are always told to ship, ship, ship!

The piece could be a lot shorter by eliminating the paragraphs of prose about lean manufacturing, only to halfway through the article state the obvious fact that manufacturing physical things does not have a lot in common with developing software. A short summary of lean manufacturing, and then the discussion of lean software development, would be more efficient.

Great article, but the bit about Web Development vs. Software Development threw me off for a bit. It seems like a pointless distinction.

I'm a software developer, my platform is (usually) the web. Sometimes it's the desktop, or a mobile device. They all have their own very special pain points. But what I do is develop software for them.

>> The fastest way to complete two projects using the same people is to do it one at a time, sequentially. Trying to run two projects in parallel using the same resources introduces a large amount of waste

Is that always the case? I have seen freelancers handle multiple projects at once using a weekly breakdown of 3 days for one project and 2 days for another.

Having done freelance work in varying amounts for a couple of years now, I'd say that task switching between two projects from one day to the next is not really a big deal. You have an overnight sleeping period for your brain to process and reset. Switching within the day, or trying to switch among three or more projects starts to break down, efficiency-wise.

No, it isn't always the case. It is only the case when all employees are fully 100% utilized at all stages of the product, which rarely happens. There are often bottlenecks where one group is blocked by deliverables from another group, and in a perfect world one could make the process more efficient by scheduling so that when those developers would be blocked they are working on the other project. Even accounting for the context switches, having the two projects worked on in parallel would be preferable here if the deadlocking blocks are sufficiently long enough.

Having said all of that, doing such scheduling well is damn near impossible in the real-world, as far as I've seen.

Reply on news.ycombinator.com