Hacker News Reader

Comment by gilgoomesh | Hacker News Reader

I think the answer badly misconstrues the purpose of "short term planning" and "continuous integration" as though these concepts preclude long proof-of-concept projects. The point of short delivery cycles is not to deliver a viable product to an external customer every two weeks. Rather it simply ensures that code remains in-sync with its intended use-case and guards against individuals going off on untracked tangents.

Basically, developers who try to develop 10,000 lines of code on their own, without sharing it for a month, create massive risks and are an impediment to their team. Forcing regular code curation and sharing among the team makes the project stronger – that's what "short term planning" does.

View on HN

Doing 1 month without integration is still fine. When agile was conceived doing 6 sprints per year would have been considered agile in many fields. The goal is to be able to be as responsive as reasonably possible not simply to add thousands of mostly meaningless milestones.

It turns out that most projects can be broken down into absolutely tiny pieces, and that is generally a good idea. However, the core idea is you need to adjust the methodology to the problem at hand and not the other way.

>It turns out that most projects can be broken down into absolutely tiny pieces, and that is generally a good idea.

Generally I agree, but I have noticed in doing things like that, no one ever seems to bother about refactoring, or tidying things up at a higher level.

Our designer complained about the CSS organization and spend a couple of days tidying it up. I have a feeling that breaking of tasks into small pieces takes away focus from more long term commitment to code organization and architectural patterns.

Some of the most beautiful code I’ve ever seen has come of an engineer going off for several months and coming back with a 1MB patch.

That kind of time allows some actual deep thought to happen. Some kinds of outcomes won’t happen any other way. I agree with that point in the quora answer.

This comes to mind as a recent example of an engineering project that had no incremental alternative: https://webkit.org/blog/9329/a-new-bytecode-format-for-javas...

I'm sorry but what's the point of a 1MB patch of beautiful code? Did this programmer actually develivered a business value for the customer or not? I'm not saying that you should not maintain your code nice, decoupled and what note, but having as a major KPI the code being beautiful to me it's non sense.

The point? Read the article. It’s a big perf win.

It’s important that it’s beautiful since the bytecode of a VM gets used so much throughout some of the VM’s most complex parts. Beautiful code is easier to use and maintain.

I read the article. And I don't really think that we mean the same thing with beautiful code.

also they don't seem to grasp the meaning of "customer" in the context of agile. if nobody ordered the software from you, the customer is you. so the project owner must be someone from the company. it can even be the scrum master assuming both roles

> I think the answer badly misconstrues the purpose of "short term planning" ...

'short term planning' appears to be your construct, not found in TFA.

Short term implies reactive / tactical -- not the planned / strategic level that TFA is talking about.

It may well be that Agile 'precludes long proof-of-concept projects', given its essence is 'better ways of developing software', which clearly hides a wealth of complexity behind the heading of user-facing software.

Agile (and XP) realised that it's a folly to plan in detail the next 5 years when likely the project, the circumstances, the business landscape, the team and even the technology will significantly shift in that timespan.

This of course doesn't mean that if you have a very concrete goal and you need to do a trial and error iterative research and development project, there is of course no need to do "agile", because the goal is fix, the things you can try is probably largely predetermined, and you already know one of them will work adequately. (Or not, but then at least you might have some form of benchmark target in mind.)

But even then, almost no endeavor starts in a vacuum, so it likely pays off to have some ability to quickly check progress (be it a CI system or just a testbed in the lab, or the aforementioned benchmark), and similarly other aspects of "agile", like try to break up the work and estimate it (think about it, its dependencies, its complexity, your competence for the particular work item, typical pitfalls), let the team know who works on what, interact with stakeholders from time to time, and so on.

Reply on news.ycombinator.com