I work for a large company, which dictates the use of agile processes. For example, for our projects, we use cloud-based services that are specifically targeted at managing agile development.

The specific engineering group I work for has not traditionally developed software (instead we help drive projects from a much more birds-eye point of view), but that is changing. We have a wide range of upcoming/planned software projects that are mostly data-centric - e.g., we will be doing data monitoring, collection, aggregation, and some reporting. Other tasks involve automation with specialized hardware and various types of client/server (multitiered) architectures. I am to assist in the process of hiring several people, and formulating many of our plans in moving forward.

My question is whether or not doing rapid prototyping (throwaway code) fits into an agile philosophy. For example, I love Python and its wide range of packages. I see the possibility of implementing many of our ideas very quickly with a Python based workflow. However, I think that there will be a lot of perceptions that Python is not "enterprise-quality", and much of this work would need to be rewritten in Java or maybe C++.

However, creating the Python prototypes would give us a lot of bang for our buck in enabling us to quickly deliver real results.

Have you been able to incorporate rapid prototyping - hopefully in Python - into a solid agile workflow in an enterprise environment?

  • 3
    Writing throw away code is a dangerous thing to do. If it works then why should the business care that it is, "throw away". It always happens unless you don't show it to them. I never compromise the quality of my code, even when I've entered hackathons. I might put the odd hack in here and there - but nothing that would be "throw away". When prototyping concentrate on the stories that make a good demo. Commented Nov 16, 2013 at 9:42
  • 3
    "large company, which dictates the use of agile" -- the funny mix of words "dictates" and "agile" somehow reminded me of Half-Arsed Agile Manifesto. Individuals and interactions over processes and tools... and we have mandatory processes and tools to control how those individuals (we prefer the term 'resources') interact
    – gnat
    Commented Nov 16, 2013 at 20:57

8 Answers 8


The concept of "prototyping", as intended in RAD, is a bit foreign to agile development. This doesn't mean it can't be done, but it's unusual.

There are different cases that need to be explored:

  1. Is the prototype an "empty shell", a mock up or a demo, built to give an idea on how a product would look like? You can certainly do it with one or more stories -- however you are building something out of your own imagination, not building a product out of real feedback. People don't evaluate a demo like they evaluate a product. For example see the feedback about our top bar prototype versus our real top bar implementation.

  2. Is the prototype something that needs to be built in order to understand better the problem space? Then it should be covered as a spike, and only its results kept (source code is transient).

  3. Is the prototype a version 0.x? A mininimum viable product? Then use the agile process of your choice for it. If you need to rebuild it in another language, you are likely to be better off if you treat that a different product. Note that sometimes this is treated as a way of shortcutting writing a spec ("it should do the same as the prototype!"). That's a really poor way of documenting a product, but this is probably better explained as a separate question and answer :-)

  • I my opinion this is the worst answer so far, I am having a hard time understanding where all those upvotes came from. Prototyping to get early feedback is not unusual, it is native to agile development. Commented Aug 26, 2019 at 13:29
  • @MartinMaat By "prototype" you mean "an early version of the product delivered to the customer that gradually evolves in the product iteratively"? In this case, of course, you are right that it's native to how agile works and the three points I make explain exactly how. That's not what people intend by that word though.
    – Sklivvz
    Commented Aug 28, 2019 at 10:46

Isn't rapid prototyping (i.e. iterative and incremental development) sort of the whole point of Agile?

It sounds like you're having issues with "perception is reality" at your organization. You might want to remind everyone that Agile doesn't mean "throw out all plans," any more than Test-Driven Development means "throw out all architecture."

And Python is not (if it ever was) a toy language. NASA and its contractors use Python, and if it's good enough for them, it's good enough for me.

  • Agreed, Python is not a toy language... However, many of the organizations at my company use Java extensively, and we will need to interface with their code, and therefore it is a requirement that we bring on people with a strong Java background. Plus it's not so much the perception of the people who understand software that is a concern - it's the perception of those who don't. Those are the people who want a name they've heard before, and that name is "Java"... I would love us to build up a team committed to Python as a primary language, but that will be difficult. Commented Nov 16, 2013 at 17:23
  • 1
    Even if you prototype in Python and rewrite part or all of it in Java, that's not necessarily a bad thing (python doesn't have the performance profile that some applications need). Having "heard" of a language is not exactly a ringing endorsement. Given the choice, I would personally choose some other language than Java, but other forces often dictate language choice. Commented Nov 16, 2013 at 18:00
  • @Robert Harvey: "Isn't rapid prototyping (i.e. iterative and incremental development) sort of the whole point of Agile?": As far as I understand, rapid prototyping means to make a quick, throw-away prototype and, after the customer has approved it, to build a real product (with proper design, etc). In agile you have a compromise between the two: you always have a prototype that is technically "good enough" (probably not as good as a system that has been designed upfront, but good enough for production) so that it can be delivered as a product as soon as the customer is satisfied with it.
    – Giorgio
    Commented Apr 23, 2014 at 10:20
  • 1
    @Giorgio: That's fine, but customers don't know what they want until you show it to them and they say "no, that's not what I want, I want this." Whether you do that in code or on a piece of paper makes no difference to me, so long as it identifies what the customer wants. Commented Apr 23, 2014 at 15:31

There is a quite stablished practice in Extreme Programing called Spike. This means that it is throwaway code. There is nothing special in it. It is just a Sprint in which the expected result is the knowledge about the throwaway code.

The above link has enough information about the good practices, pitfalls of spikes.

Your specific case of use seems a good example: it can be helpful to design the interface, validate the utility and show it to some users.


You're going to throw the code away and not put it into production (make that perfectly clear to EVERYONE), so being agile or not doesn't really matter. Any agile practices are purely optional for prototypes: sprints, burn-downs, testing, pair-programming or whatever else you plan on using.

If you're mainly going to be building functional models in Python to help product owners and other decision makers to conceptualize the project, you don't need to be enterprise ready. However, if you're creating proof of concept or trying to see if you can handle certain performance levels, you should probably stick to the production language. That doesn't mean you can't try it in Python.

Regardless, you're going to throw the code away, but have the knowledge of being able to make this work along with a better sense of what the owners want. Now you can use any methodolgy you want.


I'd add that prototypes are crucial for learning, and also in the Agile spirit. If the prototype allows you to learn, especially within faster feedback cycles, then go for it. It's all about maximizing learning and sharing learnings with the team.


In terms of learning, I'd add that prototyping gets you to learning, faster. That way, you can validate whether people even care about the problem you're trying to solve - and if the solution you have in mind is at all what they're looking for - without wasting a lot of time building a full solution that may, in the end, not solve a painful enough problem or not solve it the right way.


The true spirit of Agile is about interaction and communication. I would say if the prototype works well as a tool to help communication, there is nothing wrong to use it in Agile world. In our team (we have been practicing Agile for more than 5 years) we used it from time to time. And there are some benefits I can see from that

1) Assist communication

2) Get users into solution interviews and get early feedback


Direct communication between UX and engineers should NEVER be replaced by any prototyping artifacts. If possible, pairing with engineer works way more better than communicating through a mediator (prototype).


Others already mentioned the learning purpose of spikes. What is missing is the underlying agile principle of it which is fail fast.

One of the pillars in agile development is to recognize the hard parts and go for proof of concepts, see if you can do it at all. The classic way of working your way through all the tasks in some "logical" order may turn out to be really expensive if you find you cannot do something late in the project. Everything done thus far could be a waste.

If it has to end up that way you want to know as quickly as possible. Then the stakeholders can choose to either just stop burning money while not a lot has been burnt yet and accept what they want is not feasible or to try a radically different approach to the problem that will have a new chance of succeeding. If your prototypes are serving this purpose they are most agile indeed.

Not the answer you're looking for? Browse other questions tagged or ask your own question.