Comment by 6ren | Hacker News Reader

Comment by 6ren | Hacker News Reader

Parent Full thread

  > Haskell is a language that rewards those who sit back and deeply analyse the
  > problem, and them produce a beautiful solution.

Upfront design is the opposite of agile. As Douglas Adams said, knowing what the problem actually is is often the difficult bit. The very concept of "correctness" rests upon you already knowing the problem well enough to precisely define it.

Haskell is to programming as pure mathematics is to accounting.

EDIT: The idea of agile is iteration (aka trial-and-error). While Agile aims at understanding client needs, the concept derives from experimentation - part of the scientific method. It's also used in engineering research, I haven't failed 1000 times, I've discovered 1000 ways that don't work; in human-powered flight (reconfigurable hardware for new trials every day, instead of twice a year) going back to the Wright Brothers trying to understand flight control - they invented the wind-tunnel, to iterate designs quickly, easily, cheaply, safely (and spent 3 years on it even so). Even pure mathematicians iterate, trying different approaches.

Trial-and-error is a given in research, differing only in the level/domain of interest.

Good luck achieving your sprint deliverable when all you have is some ideas!

That's one of my main misgivings about a hard-line agile approach. It is good for shops focused on engineering simple problems or doing routine technical work. It breaks down completely in more research-driven domains.

The hard problems are the ones where you bang your head against the wall with no tangible progress, simply exploring the problem domain until you can get some traction, find a way to solve it, but often your first few attempts lead to a sub-optimal solution you'd hate to commit to.

Agile says go with it, fix it later. This is why we get stuck with crappy standards we'd all want to go back in time to fix.

Some things require a more artistic approach where you grind away at the thing until it's actually solid.

If Haskell is pure mathematics then there's no way you can shoehorn that into an agile box.

Check out Gall's Law, which I just learned about on HN. Big solutions come from iteration, not ejaculation.

Actually, agile methodologies are good for situations where the problem itself (and even customer base) is in flux and not fully known (ie consumer facing web startups). Agile methodologies help lay a roadmap to facilitate communication and prioritization to/from developer, project management, and the customer(s).

The solution may or may not be difficult, but finding the right problem to solve is paramount.

The quality of the solution is often a product of the quality of the people working on the problem. Oh, and don't run out of money :-)

My experience is there's a tendency to ship the first viable thing that comes out and deal with the rest on an as-needed basis. This is fine for stuff that can survive being a bit ramshackle at first if you can refactor it later, but some things are highly resistant to later refactoring.

Shipping quickly is often a strategy used to discover the problem space. Some things should be done as quickly as possible and some things should not. The developers/tech management are responsible for forseeing such cases.

Hopefully the initial developers are good ones. If not, I'm sorry and I hope they pay you well. I've been there :-|

So, I'm building a radiation therapy machine, and I want to make sure the software controlling it dispenses the right amount of radiation, not 100 times the right amount of radiation, because that level will kill the patient. And my problem is that my programming language isn't agile enough?

Agile isn't right for all software projects. For example, mission critical applications, like medical devices, shouldn't be developed with an agile methodology. Agile is better suited for projects that can be easily and appropriately prototyped.

Exactly my point. For some software, reliability is far more important than agility.

Why can't you have both? Maybe a different design would become apparent while developing the product, as opposed to being discovered in the analysis phase. (I'm assuming you are talking about a process with a large and separate analysis phase).

The worst case is millions of dollars spent to build a product only to discover that there are issues late in the testing phase. Wouldn't is be less risky to experiment and validate assumptions earlier in the cycle?

Agile as opposed to methodology X is a bit fuzzy here, as I'm sure testing is extensive and expensive and the feedback cycle is inherently longer, so change is more expensive.

However, it seems that early feedback and validation of design is even more important in these circumstances, since changes late in the product development process and orders of magnitude more expensive than changes early in the process.

Yeah, I'm not talking about process so much as languages anyway though. For all I know (I've never actually developed software for a medical device) its worthwhile to build an actual prototype in a more flexible language first. But if my code could kill someone, I want my tools to optimize correctness over flexibility in the final implementation.

Agreed.

Yes, because agile methodologies kill people, puppies and hate freedom.

Seriously though, in situations where lives are dependent on the solution working correctly, the process that is used to build the solution needs to take into account human error and have rigorous testing.

i.e. I also wouldn't trust a person who "though about and can 'prove'" a solution in Haskell to control that radiation machine without extensive testing.

Reply on news.ycombinator.com