 |
|
I meet with CIOs, application development groups, business analysts and architects all the time. Our initial conversation always goes the same way; I explain what visualization is and why it’s important. Within 60 seconds everyone, and I do mean everyone, GETS it. You can SEE the light bulb go on. Then….I wait for the inevitable question; “If the visualization is an exact replica of the application, why doesn’t iRise simply generate the code?” Without fail, that question is asked in every single meeting.
Actually, it’s a really good question (it must be with so many people asking it). But there are really good answers as to why iRise doesn’t generate code. Let me try to articulate them here.
- What code do you generate? That’s a tricky one, since everyone’s architecture and standards are so different. Do you generate Java/XML? .NET? SOA? Which flavors? If you had to worry about getting the code generation right, you’d quickly run out of resources to figure out all the combinations, test them and support the result. This sounds a lot like the old CASE tools strategy in the 1980’s and 1990’s. See how well THAT worked out.
- iRise is specifically designed to be easy to use for business analysts, not developers. The problem that iRise solves is getting business needs documented visually. This is a business-facing challenge, not a developer productivity challenge. If you started to worry about code generation in iRise, the product would become too hard to use and understand for business-facing analysts and usability professionals.
- Our primary emphasis is on rapid, high fidelity visualization. To put any amount of emphasis on code generation will slow down the ability to visualize the right business needs quickly and rapidly iterate to the right result. You don’t want to be distracted with figuring out ‘what code should I generate’ during this part of the process. The people creating visualizations are the wrong people to be worried about code generation - that’s the job of architects, software designers and developers.
- And of course, the flip answer is this: “There’s no button on the side of the flight simulator for the Boeing 787 that generates the airplane!” There MUST be a reason that other industries invest hundreds of millions in simulation technology without having the capability to simply press a button and build the thing. You visualize things before you build them to produce better, safer products more quickly, with lower cost and risk. The same is true with software and iRise visualizations.
It’s important to note that even though iRise doesn’t generate code, most of our customers report a 25% - 50% reduction in application development time due to the fact that proper visualizations virtually eliminate rework and allow downstream organizations like QA, training, documentation and marketing to get a head start on their work.
|
|
|
7 Responses to “Why Doesn’t iRise Generate Code?”Leave a Reply |
|
|
Mitch,
Great post. Being an iRise partner for a number of years and a reseller we at OneSpring like you are constantly asked this question and my answer is always a combination of points one and three but I truly love point number 4 and will start using that from now on. Great post I’m going to cross link this over at the iriseonline.com blog.
Have a great time in Vegas!
S-
‘Building the right thing’ versus ‘building it right’
Good post on why iRise doesn’t generate code Mitch. iRise (and other requirements simulation and design tools) help to make sure you ‘build the right thing’ versus ‘building it right’. It often seems that a development team just can’t wait to start talking about Agile, SCRUM, eXtreme Programming, script based languages, disciplined software development and all the other good stuff we’ve been focused on in the past couple of years to help us get closer to building stuff right - that is, on time and on budget. But value is deeper than just a dollar (or even £) number and a great development project is more than just efficient.
The overlooked problem is making sure you build something that’s truly valuable for the business (think effective versus efficient). A requirements simulation in iRise might not generate any code that will get you to go-live any quicker but it will help you decide what to build and just as importantly, what not to build. It’s an approach that resonates with our clients and keeps us focused on the real goal - business value.
Lakhdip
As one who both loves to simulate in iRise and loves to develop kickass UI code, I find it incredibly liberating to be able to simulate the “What” without having to spend any time thinking about the “How”. But if I were prototyping in DHTML for example, i’d be constantly trying to figure out HOW to incorporate the latest round of changes, and worse, I’ll be hesitant to scrap a pile of code that I’ve invested blood sweat and tears into — finding myself defending it, and trying to adapt an increasingly complex situation to changing requirements.
With iRise, when a better idea comes up, it’s no problem scrapping the old model and starting over again. And once the model is finally approved — the real fun begins: figuring out HOW you’re develop it
Hi Mitch,
Interesting post. Being able to engage business folks to visualize the “what” without spending time thinking about the “how” (as Marty stated above) is a nice application design innovation. However, it doesn’t mean that you shouldn’t also be able to generate the solution from your simulation.
Although funny, your number 4 point is an apples to oranges argument. Using a software program to simulate something you will “cut in stone” with hardware is not the same as using software to simulate software. It makes sense that you would take the design from software simulation and use it as a design doc for creating the hardware solution (hardware and software are different domains). However, it doesn’t make sense to use the output of the software simulation simply as a design doc for a software solution – it’s the same domain.
Conceptually, simulation makes sense – throwing the software away doesn’t.
Hey, Mitch:
Like Mike Evans mentions, your allegory is good, but only goes so far. There are other industries besides those that use physical CAD from which to take a lesson. Besides, simulation in the physical area also allows some generation of “code”, most often in the form of things like accurate Bills of Materials, etc.
I agree with Mike that the real comparison is to those things that exist in software, and there are ample examples of successful implementations of simulation-to-code in that arena. One is the decades-old electronics manufacturing industry, where library-driven software now converts electronic CAD files into programs for automated testing machines. These same CAD files can be used to generate component placement programs as well.
There are three corollaries to software generation:
- There is a plethora of target software environments that have completely different code bases, but which use the same simulation base.
- The resultant code can be generated with a single click in seconds, making re-generations from library changes almost effortless.
- The resultant code is almost always about 80% there, leaving room for the necessary creative bent of the test and manufacturing engineers (architects, developers).
Bear in mind that this capability only resulted after years of work to make it happen. The first step, though, was the effort of visionaries who realized it could be done, then set about to do it. Those who lacked the vision and insisted it wasn’t possible (and they were legion) left a bunch of money on the table.
NewBA
What then, get handed off to the development team. What is it that iRise generates that the development team can leverage???
Thanks!
Stephen,
There are two artifacts generated by iRise; the simulation and a functional spec.
With iRise, development teams can now receive a fully functional, high fidelity prototype for what to build, along with the functional spec. generated by iRise. This is important for developers because:
1. it forces the business to articulate what they want in a language everyone can understand
2. it doesn’t allow the business to change their minds in the middle of project without specific discussions about ramifications
3. visualizations get the business off the backs of developers while they are designing, architecting and building the software
4. accurate visualizations are proven to eliminate rework; no developer wants to endlessly recode projects due to miscommunication of requirements.
Hope this helps. Feel free to email me at: mbishop@irise.com if you have further questions.
Thanks,
-Mitch