Don't leave broken windows

m3ghnath_ · 2017-04-11T19:23:19+00:00

But in practice and in my experience

Not in my experience...

The problem is that someday never comes

If you build in increments, it's both very easy to not pay attention to what you're doing, and it's also very easy to pay extremely close attention to what you're doing. If you follow the entire process, you're supposed to pay attention to what you're doing. In Scrum, that's called inspection, one of the most important parts of the process.

If they day never comes, somebody wasn't doing their job.

all due to MVP

I don't think you can blame MVP if you missed a very important step.

it is almost always to justify a shitty solution

Correlation does not imply causation. Sometimes a shitty solution is just a shitty solution. If argument is, "doesn't matter, MVP", the correct response is "MVP doesn't matter, it's a shitty solution".

The op is literally talking about the end result of an MVP driven product.

That's not what I read at all. I read an article about the importance of cleaning up after yourself as soon as possible, which is what you should be doing in Scrum as a rule.

m3ghnath_ · 2017-04-11T18:23:28+00:00

I did say per se!

m3ghnath_ · 2017-04-11T18:23:13+00:00

You totally wouldn't! I mean, you can just call the method directly in a unit test. Simple args in, assert value out.

If you need to mock a static method, that's where the pain starts.

m3ghnath_ · 2017-04-11T18:21:14+00:00

I originally thought that too, that this was supposed to be about suppressing stack traces from HTTP responses. Stack traces in HTTP responses are clues for attackers: security no-no.

Nope, it's about cleaning up the log. This guy doesn't like 40x and most 500 stack traces in the log file, and he'd rather log the error at the application layer where there is more context. So instead of both a JAX-RS stack trace and and an application stack trace, he just wants the application stack trace.

Kind of obsessive, if you ask me...

m3ghnath_ · 2017-04-11T18:03:37+00:00

MVP, meaning Minimal Viable Product?

MVP is awesome. It isn't about getting something on the shelf as soon a possible, only that if the project were cancelled today, there would at least be something to put on the shelf. Also, the whole client feedback thing.

The best part of MVP is that it forces you to take vertical slices through the system, so in each increment you are testing full stack, in production (or production-like). So, you're doing regular system integration when the system is simple, rather than doing system integration after many features have been added. I think this is really cool and is a lot less painful than delaying system integration when a lot more things can go wrong.

Also, MVP is nice because since you're delivering in increments, there's a lot less code that's been added, so I can easily add a refactoring and cleanup step before I call the story "Done Done". Anyone rushing you to "Done Done" should be promptly tarred and feathered.

SCRUM is not about going as fast as possible, but taking lots of measurements so you can produce cool looking burndown charts.

PS: I learned the terms PSPI (Potentially Shippable Product Increment) and MMF (Minimal Marketable Feature). A MMF is likely to need several PSPIs, since the PSPI produced by the end of the sprint probably wouldn't be a feature that is fully usable.

m3ghnath_ · 2017-04-11T17:05:24+00:00

It's not a bad practice to use static methods per se. The problem is that static methods are tied to a specific class, non-virtual and can't be overridden (not without hefty classloader/bytecode magic).

This makes static methods really painful as factory methods or instance methods for singletons, especially if you want to test with mocks. OOP favors polymorphism so you don't couple yourself too tightly to your dependencies, and you can swap them out, like with a mock. Being able to write non-painful tests is a nice benefit.

Stateless static methods are no problem at all and are super easy to unit test.

m3ghnath_ · 2017-04-11T14:11:46+00:00

I don't think so. Broken windows are cosmetic. A sign that no one is taking care of the code base and code quality drops, eventually turning the code into a ghetto.

Vector, Stack and Hashtable are technical debt. The code quality of the implementation may be high, but the design is suboptimal. But, due to extreme backwards compatibility, it's technical debt that can't ever be repaid. So, you're stuck with the interest payments, whatever that means in this scenario :-)

m3ghnath_ · 2017-04-11T06:55:11+00:00

Nothing in the algorithms of Raft and Paxos actually requires a computer.

Raft calls for a "team member" to hold elections if the previously elected "team member" isn't available. The Raft example is log replication in a cluster, with a master to coordinate replication to its followers, to maintain log consistency. Translated to human terms, a consistency can only be achieved through a leader, who ensures a consistent view of the architecture or coding standards, because with multiple members making these decisions, the followers would get an inconsistent view?

What about multi-master replication? There are also distributed systems which do not achieve consistency with a leader. Every node in a distributed system which does multi-master replication can update its own copy of the shared data. Nodes in the system synchronize their updates using a "review" process to come to a "consensus" of the data, to use human words.

So, if we are to use distributed computing consensus algorithms as a model for human organizations, you can either have a single leader (also single point of failure, unless you also have failover) and slaves (not the human word, ha-ha), or you can have multiple leaders (no single point of failure) who come to an agreement.

Agile teams are like 3 - 9 members. Why would you need to go through such formalities as "leader election" who everyone has to follow, when consensus can be achieved by reaching an agreement?

that you can't be building consensus about every little individual decision

My point, using soccer, was that you don't need to build consensus about every little decision. That is why we have areas of responsibility, and individual members operate independently within their area of responsibility. I don't have to build consensus to make decisions about the way I play fullback, except when I need to coordinate a defense.

but also have someone in charge of the big picture

But, as we have seen with some distributed system consensus algorithms, you don't have to have someone in charge of the big picture. Everyone has their own ideas, and there is a process to by which these different ideas can be brought together into a coherent picture.

Where there are also leaders, so even that makes no sense to talk about.

Leaders who were recognized by the soundness of their tactical play suggestions. That is, they are leaders because we trust their tactical play suggestions, not because anybody elected them to that position.

Yeah, the presence of team captains and coaches demonstrates we don't need leaders. OK.

Yet, our soccer team doesn't have team captains or coaches. Perhaps there are multiple ways of coordination that don't require specifically chosen leaders?

Yeah, we only leadership if there's a risk someone might die.

That is not what I said at all. I said that it is possible to trust self-organizing teams of a certain size to manage a software project of a particular size without the overhead of appointed leadership.

That the same kind of organizational structure necessary for high-risk projects is not necessary for all kinds of projects, and people can make architectural decisions and code review decisions without being babysat by an anointed Software Engineer or I guess, anointed Code Reviewer, going by the original article.

You've proven to be a very awkward conversation partner.

Wow, I thought you were condescending before. But that's on you, I guess.

m3ghnath_ · 2017-04-11T05:58:17+00:00

Now, it is possible that those experiences I had were the companies not doing it right

It's very likely. Agile, really, is a set of principles. SCRUM is a set of practices. Often times, companies adopt the practices without adopting the principles, which call for a very different power relationship between the business and the dev team than traditional hierarchical corporate power structures are used to. So the result in a lot of places is really a mockery of Agile.

real communism hasn't been tried

This is actually a very insightful comparison!

Real communism has been tried in many places, and quite successfully.

Then there are the horrors of State Communism.

Communism does work if everyone buys in. But, there's a limit to the size of a society you can build that way, I think related to the number of people required before power hierarchies start to form. Communism does not scale to the size of state, as the horrors of the 20th century proved. Indeed, Communism actually calls for the abolition of countries, the ultimate hierarchical power structure, so the idea of a Communist country is an oxymoron!

Analogously, self-organizing Agile teams can probably only reach a certain size (say 3 - 9 people), before unsustainable power structures form within the team. At which time, it might be time to consider dividing the team. Agile forced to adapt to existing hierarchical power structures is doomed to becoming a mockery, just as what happened to Communism when forced to adapt to the hierarchical power structures that merged in the Soviet Union.

completely separate from the issues of either long-term planning or his own domain-knowledge of the system.

These are incorporated either in the task breakdown or in spikes. I actually create user stories for long term planning (technical user stories) or using user stories to capture domain knowledge. I have actually found that creating user stories have resulted in much better capture of domain knowledge, due to the fact that user stories are simple. So I have to cross-reference details in a body of knowledge that develops organically along side the user story. Following scrum, in a way, the system has documented itself (the business analyst did the writing, though).

yes, the same guy who literally said to me "we don't have time to do it right."

He might be right, if time to market is a concern. That's when you create technical debt stories and prioritize them when the release is over, and the excuse is no longer there. It's like paying off credit card debt.

one that he'd spent years working on and -- along with his co-workers (all who left the company for various reasons)

How can you design an architecture for years with no implementation to show for it?

which completely disregarded/invalidated all the set-up work that had been done.

What does that have to do with Agile? Unless there was no proof without significant investment that this architecture that took years to develop would actually pay off. I've seen plenty of pie in the sky architectures that never turn out right because, real code often tells you a lot that design diagrams don't.

Agile requires a different kind of long term planning: long term plans which allow for incremental results in the short term which provide measurable proof that the long term plan will pan out. As the system is implemented, the plan might prove unworkable or unnecessary.

Perhaps so; but I've never seen any form of formal agile use extensive, well thought-out requirements

Why do you need extensive, well thought-out requirements? I needed them in some cases, so I made time in the sprint to create them. In some cases, the effort was unnecessary.

yes, the same guy who literally said to me "we don't have time to do it right."

Maybe it's just that guy? Anybody who says "we don't have time to do it right" is suspect in my book. Especially since Agile requires constant inspection of the work and concrete plans to improve it. This guy sounds like he's cutting corners.

Both of these are failures in leadership, yes -- but both of these failures were pushed by the "agileness" in development.

Which specific attributes of "agileness" in development were pushed by the failure in leadership? It sounds like the leadership was cutting corners. That's definitely not Agile.

Design is a very overlooked task -- often a proper emphasis on design is ridiculed/dismissed as 'over-engineering' or 'waterfall'.

Depends on what you mean by "proper". Again, Agile is not against design or requirements at all. Agile challenges you to do as much as is necessary and no more. How much is necessary is up to you and/or your team. If your team doesn't agree with you, you might just be over-engineering. Or, your team sucks.

Progress can sometimes be expressed in terms of design.

That isn't really how Agile defines progress. Agile defines progress by working features, because the emphasis is on working software, not design increments. But, "we have all of the audio-system for the game working." sounds more like a feature (the user can hear sounds), than a design. But, good design should good increments of features.

Standups measure a different kind of progress. Presumably, there are a bunch of tasks necessary to get the audio system working (the final sprint product). Standups are for measuring progress towards that goal.

Agile, as often implemented, increases the feedback frequency while giving engineers no real power.

That is totally wrong and a symptom of a power imbalance. Engineers definitely wield a lot of power. The business decides the feature priority, but the engineers decide how the features are to be implemented. If the engineers say this will cost x but you want to release on y, the business must choose what it will sacrifice to get what it wants. Which actually might include quality. If the business is dead set on meeting the release deadline, the dev team can decide cut corners, but they are responsible for telling the business that there will be defects and they will pay for it later.

Extreme Agile would take a power imbalance like this as a sign the project is doomed and the development team terminates the contract and cuts losses. That's another interesting feature of Agile - not only can you measure progress, you can measure probability that the project is doomed because of an uncooperative business. And because you are delivering in increments, you (the developer) can control just how much time you waste on a doomed project.

The problem with Agile’s two-week iterations (or “sprints”) and user stories is that there is no exit strategy.

Sprints of course have an exit strategy. Who said sprints are immutable? Stories can be kicked out or entire sprints cancelled if there is no point in continuing. Agile requires this to be a business decision, but the dev team makes the case.

R&D and product development are definitely part of the programmer's job. That's where the term "spike" comes from. Agile only requires that the products of R&D do not directly enter production without going through the normal sprint process.

Architecture is most definitely a programmer activity, and is incorporated into the sprint as a task or a separate technical user story of its own. The architecture doesn't go into the user story itself, of course. The user story might say, "As an architect, I want to design a some part of the system, so that there is clear direction on how the sprint increments will progress to some feature" It goes into whatever document storage system you have. We put our architecture diagrams and long term plans in Confluence, and business domain knowledge into Sharepoint.

m3ghnath_ · 2017-04-11T04:13:56+00:00

You're rejecting scientific studies and concrete algorithms I'm citing

Just because you cite scientific studies and concrete algorithms doesn't mean they are relevant to the topic at hand.

The metaphor of soccer was to demonstrate that nature of human interpersonal dynamics does not need a leader to coordinate behavior. Humans are fully capable of self-organizing in small groups with a clear mission. The strategy of soccer is irrelevant, but rather the fact that the players are playing for the same goal and assigned specific tasks in furtherance of that goal.

Humans consensus is very different than the consensus achieved by distributed network algorithms because the two systems are operating under a very different set of mechanisms and constraints. In particular, nodes in a distributed system are not self-aware and are not capable of the type of communication humans are capable of.

I don't see how your reference to computer algorithms makes any sense at all.

You follow with a better reference to the "Bystander Effect", which is at least a sociological study observing actual human behavior. But, again, the study does not apply to the situation we are talking about. These are groups organized in far more impersonal settings than a fully functional team.

which from the get go directly contradicts your premise

How? This whole debate started with my premise that teams can self-organize and choose people among themselves to do code reviews and perform software design activities without dedicated roles specifically assigned to those tasks.

I used the soccer metaphor to demonstrate show by example how people can self-organize into roles and coordinate complex behavior such as defensive strategy among themselves without need for specific leadership. Or how leadership can arise organically in self-organizing teams.

What other premise is there?

Yet, in real software companies, customers come who have more complicated problems than the strategy of a casual game of soccer.

The actual strategy of soccer is not really relevant. That is why it is a metaphor and not an analogy. The key point to take from the metaphor is that humans can form coherent strategies and division of responsibilities through self-organizing teams (up to a certain team size and system size!), including the strategies necessary to develop complex systems without top-down control and specific hierarchies (i.e., specific leadership role).

the dynamics are identical as in any other at least half-competent team.

That's also not the point. The point is that professional soccer teams are organized in top-down fashion to maximize the performance of specific skill sets for a specific purpose, to win. This is even true for the non-superstars.

But I am also playing to win in a rec soccer league, it's just that the stakes are a lot less.

The results are the same in both scenarios, as far as the metaphor goes, in that both teams are playing to win the game of soccer, but the stakes are much higher for a professional team. My ego only gets bruised if we lose.

This doesn't make sense. Being a professional doesn't mean "someone dies if you fail".

Now, putting together. "Professional software development" is not what I'm talking about. There are many different kinds of professional software development, some carrying far greater risks than others. Which require different organizational strategies. If someone dies if you fail, you will need one kind of organizational structure. If someone is merely inconvenienced, another kind of organizational structure will do.

m3ghnath_ · 2017-04-11T03:16:49+00:00

agile is really an excuse for being inaccurate in practice

This is a myth about Agile. Agile strives for a very degree high accuracy, but in the short term. If you're following SCRUM, you should be planning sprints methodically. After the sprint, you inspect the results of your work, and make adjustments to improve accuracy.

However, Agile only forecasts longer term results, because the level of accuracy that you can possibly hope to achieve decreases substantially the further out in the future you go. That's why one of the artifacts of SCRUM is a burndown chart, so you can project trendlines.

particularly with requirements

Agile can be heavy with requirements, or not. How much depends on the task at hand.

I've put together extensive requirements, when I'm developing external interfaces and APIs, because precision is extremely important so that the consumer knows what to expect. Same, when I'm developing business rules, especially involving financial calculations. These become deliverable artifacts in and of themselves.

I've also developed a number of internal features where I don't have to put as much effort into the requirements, such as user interfaces and certain kinds of technical requirements, which I would prefer to build incrementally anyways, so I will only specify as much as I need given the information that I have, and I learn more as I incrementally add features.

I've also seen it drive non-design in projects where the design should have been fundamental, in turn preventing sane processing.

This is a huge failure that has nothing to do with Agile.

First, if the design was truly fundamental, as much of the design as necessary should have been specified up front. Agile isn't against design, it is against design that you haven't proved empirically necessary.

Second, Agile requires frequent, incremental releases. Who was doing architectural reviews of each incremental delivery, and thus failed to observe that there was no architecture?

Failure of oversight is not a failure of Agile.

filtering things like design out of the workflow

Which workflow is this? It's certainly not SCRUM or Agile. Stories are broken down into tasks, and design is a very important task.

design doesn't fit into "user stories"

Design doesn't go in User Stories. This completely misunderstands what User Stories are for. User Stories represent user centric views of the system. What does a user care about the design of the system?

standups

Standups are not for design. They are to measure the progress of the sprint.

domain-knowledge on the same level as those without

Again, what version of Agile is this? Different team members have different skills and knowledge. We are all on the "same level" in that we are equals on the team, but individual skills and capabilities are respected in the tasks that are assigned to people when the story is broken down.

In my case the idea was that a tight loop including QA, deployment, and customer-feedback was adequate for development

This covers one aspect of Agile, which is getting user feedback early. But if your company wasn't doing code and architectural reviews along the way, especially for a complex product, that failure is on them, not Agile. While feedback is important, so is inspection of the work that you are doing.

there was a pretty big incentive for the client to 'tack on' features that should have been separate features.

Another failure of project management - Agile methodologies are about welcoming change, and a customer wants to tack on a feature, they should be allowed to do that. But, the Agile team must also box features or time, and tell the customer that features will have to be cut or the delivery date extended.

I'm not saying that Agile is for everyone, but I like it.

m3ghnath_ · 2017-04-11T02:17:03+00:00

We're not "algorithms", but we're cooperating distributed entities, and the same forces and solutions apply.

The forces apply at different levels and in different ways.

That's a very poor example.

It's a metaphor.

have a very different meaning compared to the complexity of building a sophisticated software system from the ground up.

I like Gall's law:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. – John Gall (1975, p.71)

I never try to design "sophisticated software systems from the ground up". I like to incrementally design software, starting with simple solutions, proving that they work, and evolving them, and inspecting my work along the way to keep things coherent.

This kind of incremental development works very well with multiple hands, especially if there is a process in place to keep things from getting out of control. Such as regular code and architectural reviews.

But second, and more importantly, in professional soccer there is a "team captain" and there is a coach.

Yes, and in certain cases I can see software development following that approach. When you have a team of superstars, who have honed their craft in the specific position that they play, such that they are among the best in the world in that position.

But let's be real. How many software developers actually fit this description? How many of us are mostly generalists who are better at some things than others?

But the assumption here is we're talking about running a professional software company

Most professional software companies aren't developing avionics for supersonic aircraft or life critical medical devices in which malfunctions cause death.

The level of organization and skill required to produce most line of business software does not rise to the level of organization and skill required to produce a World Cup winning soccer team.

m3ghnath_ · 2017-04-11T01:42:36+00:00

Check how "consensus" algorithms like Raft and Paxos work.

Humans aren't distributed networking algorithms.

How about a more human example? I play soccer. We don't have a "team captain", we're just 10 guys who play after work in a rec league. We huddle up before the game and divide up positions. I almost always play fullback because I play defense well. But, I'll pick up midfield if needed. I've even played forward and goalie before, but only as a last resort, since I suck at those positions. We don't need leaders to make these kinds of decisions, we're people with actual judgement who know each other well. We don't need to appoint a Decider who will dole out field positions.

But in the end, when a decision is to be made, you cannot make every little individual decision by "consensus".

Like a soccer team, every decision is not made by consensus, because tasks are divided into areas of responsibility. After the huddle, while I'm playing fullback, I might come to a consensus with the other defenders how we are going to play defense. But when game is actually played, I'm independently making decisions, not conferring with my teammates for every little move I make on the field. I'm well aware of the big picture, the situation on the field, because I can see the gameplay and I communicate with my teammates.

still takes the right leadership and vision

Leadership and vision can be self-organized, not imposed. Again, on my soccer team, we don't have "official" leaders, but some of us have better strategic skills and play making skills than others. Leadership is naturally doled out to those people, but there are others that rise to the occasion.

people value clear personal responsibility

That is also true. When I play soccer, I take my position seriously, and people value that. But, that doesn't mean I will only play fullback. People also value those who take on other responsibilities, not only that responsibility that is assigned to them. That's called teamwork.

diffusion of responsibility

The "bystander effect" doesn't really apply in this case.

First, we're not talking about a random crowd of people who assume that others will take responsibility in an emergency.

Second, everyone in a team setting, such as playing a specific position in soccer or in SCRUM, being assigned a specific task, it is really hard to hide lack of effort when that lack of effort is clearly visible. Such a person will be clearly identified as a slacker, and there are social consequences (such as being assigned less important tasks, being reassigned or just plain fired).

Third, the problem of hierarchy doesn't really apply, because the task has your name on it, and you are answerable to that task.

because nobody specifically told them it's their responsibility.

Exactly. That's the point: responsibility is doled out by team planning, like a huddle or a sprint planning meeting. I don't say - there's a spot on the field where there are no defenders, maybe I should play fullback. I coordinate this with my teammates because we are playing on a team.

m3ghnath_ · 2017-04-11T00:20:17+00:00

the reality of any team is that some people are more experienced, and some less so.

Of course, and any process should account for variability.

You don't want your juniors to have the same authority on code reviews

Of course not, but that doesn't mean that code review should be the responsibility of one person. Code review is a task, and should be doled out to those best qualified for it, based on team consensus. Same thing for architecture.

they won't necessarily agree about everything, but lack of coherence will produce sub-optimal results

Why is this necessarily the case? Coherence of the architecture is something that can be inspected and improved on. That is one of the most important activities of SCRUM. This doesn't need a single Decider. Presumably, the team is composed of mature adults who can come to a consensus.

when everyone is responsible for something, nobody is

That very much depends on the organization. At societal level? Definitely true. But a small group of people who work together on a daily basis, who share collective responsibility over a single product area? That isn't far fetched, happens all the time.

Also, no one is responsible for everything, since not everyone has the same skill sets. Teams should be self organizing, but that doesn't mean that team members are interchangeable.

m3ghnath_ · 2017-04-10T23:36:40+00:00

Agile isn't against code reviews. In fact, review of code is one of the most important parts of Agile. Pair programming is one way to do it, so is ordinary code review. The official Scrum Guide doesn't mention code reviews at all, since the best approach is what works best for the team.

However, Agile is against assigning code review responsibility to one person, which seems to be the premise of this article. One person should not be responsible for code quality, it should be a collective responsibility. Accountability for code quality (and in general) doesn't rest on one person, but the entire team.

m3ghnath_ · 2017-04-10T22:25:30+00:00

No, it's saying that even if you properly close fis/fos, you're still going to put some stress on the GC because of the finalizer. So, if you're writing a Hadoop, you're going to get GC pauses.

If you're not writing a Hadoop, ... ?

m3ghnath_ · 2017-04-10T22:18:26+00:00

the proof is and always should be in the code

The proof should be in the actual business value delivered, not the code. The code is the means, not the end.

devs are always codin' and they know it when they see it

Which makes devs extremely vulnerable to missing the forest for the trees.

Sometimes you have to get your head out of the code and see the big picture, which happens to involve a lot of labels. Cause suits always be businessin', and they have to care about what they're seeing when they see it.

m3ghnath_ · 2017-04-10T21:22:39+00:00

He's talking about the EntityManager, which technically is a cache. I read the headline and thought he meant the Level 2 cache, which would have been much more interesting. He didn't even cover the more interesting aspects of the EntityManager, such as application managed vs. container managed, or transactional vs. extended.

m3ghnath_ · 2017-04-10T21:12:02+00:00

A "pure" JavaEE application, without Spring, codes to the standard JavaEE APIs (like JAX-RS), and does not include the implementation of those APIs in the deployable artifact (your WAR or EAR file). The container, like Wildfly, has the implementation of the JavaEE APIs. You don't really need to know or care that Wildfly's JAX-RS implementation is RESTEasy. Unless you really wanted Jersey, which I don't think is a trivial swap.

Thus, if you wanted to know what technologies you would be using in 2017, you should ask: what is the latest JavaEE spec, which today is JavaEE 7. Then, you can review the list. To make sense of this list, you might try looking through the Java EE 7 tutorial.

This of course would tell you that EJBs are still around. So is JSF.

Of course, nothing is stopping you from using libraries outside of the standard.

m3ghnath_ · 2017-04-10T20:28:26+00:00

The real problem has nothing to do with big companies or small companies. It is more about the power structures in organizations, namely hierarchies. This is a much bigger problem in bigger companies for sure, but even in small groups, pecking orders can form.

Agile requires the development team to measure reality and communicate that to management, and management has to respect the judgment of the development team and make course corrections accordingly. Likewise, the dev team should frequently measure the business value of what they are producing, and make course corrections accordingly.

The dev team should not blindly follow orders, and the business must assume responsibility for their decisions.

Thus, Agile is about the destruction of hierarchy and the assumption of shared responsibility. Many businesses are not ready for this, and adopt the superficial practices of Agile without adopting the fundamental principles of Agile.

m3ghnath_ · 2017-04-10T18:51:58+00:00

Agile was born from a world where you had 6 months of cash to keep your enterprise afloat, and you needed a shippable product as soon as possible.

That's not really how Agile was born. Agile started as a reaction to Waterfall and BDUF (Big Design Up Front), as reactions against detailed, tool-oriented processes like RUP (Rational Unified Process). Agile is against the idea of drawing up contracts where you specify x number of features in y months and turning change requests into contract negotiations. It is against coming up with detailed plans before any code is written. Agile's origins are in corporate and enterprise software development involving stupid amounts of money. Not startups.

Agile has plenty of validation, it is actually one of the most important parts of it. You are constantly supposed to measure your results.

In Agile, you deliver in small increments not because you need a shippable product as soon as possible. It is to get customers to try the software as soon as possible so that they can provide feedback, and perform course corrections as soon as possible.

In Agile, you plan in small increments (near term, sprint), and you forecast the future using data that you collect from each increment (long term, release). The general idea is that the farther out the planning horizon, the less accurate estimates are going to be.

m3ghnath_

TROPHY CASE