Reading the Pragmatic Programmer on and off for the past few months. I have an extremely short attention span, so when I’m burnt out of coding, the History Channel, and the Legend of Dragoon all at the same time, that’s when I read. Fallen tree in my backyard, bills, sending invoices, laundry, and the rest are only done in dire circumstances.
I haven’t gotten all the way through it, but I managed to hit the part about “Tracer Bullets”. They discuss the two traditional ways of developing (enterprise) software (as of 2000).
The first is where you gather a few non-specific lists of requirements from the customer, document it to hell in the form of “business requirements”, sign off, code for years in a dark cave, bring all the modules together, fix the bugs enough to get a working build, and deliver to the customer. Naturally, there are tons of problems with this approach, but I see this repeated time and time again in larger companies.
The second is their tracer bullet approach. You basically build a shell of the app you think will work, get enough of the skeleton working so you can compile, and show to the user to get feedback as well as understand any performance issues (if any). While slower on the uptake for the developer since you’re building the real framework, it’s quicker for the user & management to actually see progress. The user’s can more quickly give feedback, and you can more accurately see if you are “on target”, and where you should adjust accordingly, with real, already working code. You continue with the same code base you started and the user accepted the first initial build. Sounds a lot like Agile Development.
The third is the prototype. Disposable code, written for the sheer point of proving, or disproving, theories. Will this design work? Will this algorithm scale?
Prototypes are great to get a design in front of a customer with fake data to see if the wire frames/storyboards accurately depicted what the user wants without spending copious amounts of time implementing the GUI. This plays more of role in things like C or Java where GUI work is more time intensive than something like Director or Flash, which buys you more time to try more ideas, or further refine existing ones at a cheaper cost.
The second is to test your algorithms. Whether that be in the same language (ActionScript) or you’re just using AS1 because it’s lighter weight and quick, like JavaScript just to do a proof of concept. Strict data typing, classes, and the like get in the way if getting something done quickly. They help you during debugging & maintenance, that’s why you use them. If you want something done, and done fast, using a loosely typed language frees you from unnecessary restraints to get a prototype done quickly.
It can also be said that prototypes offer a low-risk entry point to software. If you spend 2 weeks of balls-to-the-wall development to get a prototype in front of a potential client, and it fails, you only lost 2 weeks vs. 3 months. If however your client wants tons of features for v1 and expects them to happen in another week, you’ll have a tough time explaining why it’ll take 3 months just to get to the point where you are now so you can then spend another month adding those features. Thankfully, that’s not my job… yet.
Game development is another potential area which can benefit from prototypes since you have to be pretty much half-done to pitch an idea, even when applying for a license to an existing brand.
Now, in my profession I do everything in the same environment and language. I code in Flash or Flex Builder, usually in AS2. ActionScript is flexible enough of a language to allow you to write both the quick stuff, and the more time consuming strict typing stuff. Apparently in other professions, you realize that you can spend 3 days writing your algorithm in something like Python vs. C, and save that much more time down the road. When comparing AS1 to AS3, I can understand why.
Spending copious amounts of time writing:
en override public function getName ( id : Number ) : String
vs.
function getName ( id )
…or a 500 line app that you have no intentions of maintaining, debugging, nor putting into production. Not to mention the fact AS1 is case-insensitive if compiled in Flash Player 6 or below.
I think a lot of my career was built on prototypes… at least, according to the Pragmatic Programmer.
Yes, I’ve written software that was not a prototype, but I still think the majority of my work, even if not viewed as a prototype, was if using the above criteria. Now, hindsight is 20/20 (to the beholder anyway), this doesn’t mean me, my former teams, or any of the companies I’ve worked for could of done anything different at the time. It’s just an reflection I have finding commonalities with my experiences and the concepts in the book.
Adobe (at the time Macromedia) once akin Central to having the aptitude for disposable apps. At the time, there were 2 specific applications for Central that had a warm reception for the most part. One was an application for conference information on MXDU 2004. The second was one for MAX.
When you look at it from the 30,000ft. view, it makes sense. You code a minimalist back-end to get just enough working data, bust out a design, implement in Flash, code enough to get her working, and deploy for a hard deadline. Hard meaning, non-negotiable, non-changing. After the deployment date, the app has exceeded it’s usefulness, and thus its lifespan. At that point, it’s merely a point in history with which to use for reference in essays like this.
It’s disposable. It’s a prototype.
…but it’s also a solution. It worked, satisfied the goals of the project, solved the problems the software was created to solve, and was successful. There were no tracer bullets fired, business requirements were 1 page or less, consisting more of a contract-to-hire and days of furious coding.
I’ve seen that same scenario played out over my technology tenure, except with non-hard deadlines, particularly with Flash projects. One of the reasons I transitioned from Director to Flash for my multimedia projects was because it was faster to get things done, and I could have my entire team work with me. It was RAD, rapid application development, to a point. Flash empowers you to get things done, and get them done quickly with a lower barrier of entry (unless you’re a server-side, anti-GUI/pro-AJAX Java developer, in which case when you wake up in a cold sweat, know that the timeline is out there… in the dark… waiting…).
I’ve seen cases where documentation was done out of sheer CYA (cover yer arse) from past negative experiences. In the end, it didn’t help. All that mattered was how fast you coded, and how well she worked. If the user didn’t like it, you either re-coded, or spent long nights & mornings untangling spaghetti code to “friggin’ work!”.
The point of a prototype is to challenge assumptions, identify risk(s), and confirm good technical decisions. The point is not to deliver software because of the results of the above described process.
From a business retrospect, I don’t think it’s sad. If you look at a lot of some of the older projects that have been done with Flash, from movie websites, games, e-learning, and modules into larger applications… they were launched, the customer was happy, and people got paid. Flash, for those who were in the know, got a great reputation. I don’t think all were developed as prototypes by the Pragmatic Programmer’s definition, but I know many that were, and the untrained eye wouldn’t know the difference on most (aka, the user).
Still, I think it de-values good software in a way. I’ve made the comment copious amount of times about how, “I never ‘maintain’ Flash projects I’ve created. Preposterous, just re-write!”. While true, I’ve also found re-writing easy and fast, mainly from the tool & language, but also from a development perspective; developers like to create, most don’t like to maintain, and we all always hate our work and want to do it over, better the next time.
That attitude has actually served me well, but only because I’ve been mainly in the service industry vs. the product industry. Meaning, every job I get, full time or contract, is always something new for a new client rather than a software product I create on my own terms and maintain.
The mere fact I know OOP, MVC, ARP/Cairngorm, and other design patterns, while having everything to do with wanting to do things “better”, has resulted in usually larger scope prototypes rather than converting me to product work where such things are more applicable. I am merely more adept at handling & reacting positively to scope creep. Granted, a lot of service work is to create enterprise solutions for large customers which have long life spans… but I’d argue those are products. Still, it can go both ways. You can use Cairngorm in a Flex prototype as well as in a finished product.
Is this bad? Do customers really know they are getting prototypes? Do they care?
For most projects, I’d say no. Working software is working software. Given the challenges, that right there is success. A lot of the smaller scale Flash projects I’ve seen or done aren’t usually maintained, or changed a whole lot later in life. This could mean a lot of things, like they got it right the first time, the goals need to be hit one time, or there really isn’t room to grow (room meaning budget), etc.
Do customers care? Don’t think so. I do think however clients I work for do. 3 months up front costs you less after the fact vs. 2 weeks. The project will still take 3 months no matter what resources you throw at it. If you want it done faster, you have 2 options:
– create a prototype in a short timeframe knowing that the cost of changes & maintenance will be astronomical in the time they take post-deadline. Therefore, you’re better off coding from scratch after you hit the deadline. (See the pattern?)
– hire some serious bad-asses who can create prototype code, using existing portable classes from their repertoire, and pass it off as a product vs. a prototype. This’ll cost you more bling as well.
So, if customers are users, no. If customers are clients you are coding for, yes.
I haven’t gotten to the chapter of “Good Enough Software”, so maybe that will provide more insight. I will say, though, that the only reason I’ve been able to survive this long is because of Flash & Flex’ flexibility combined with my learned skills to manage scope creep. If I were trying to do the same career over, except in something lower level like Java, I think I’d kill myself. Not on purpose, mind you, just because of the stress my body would just shut down. Object.prototype, MovieClips, and a portable runtime (Flash Player) have gotten me out of more jams under insane timelines.
If I ever start a company, I’ll clearly articulate the difference between a prototype and a product to my customers since I still feel it is not within an engineer’s decision jurisdiction to make the call on what is more appropriate for a project; prototype of non. Sometimes deadlines are make or break, non-negotiable, failure is not an option endeavors. In that case, there is no question, only action.
The prototype is cheaper and faster to build, and time has shown prototypes can function quite well in deployment. The trade-off is they don’t scale (sometimes), and the change & feature addition cost is extremely expensive.
A product on the other hand takes more time to build, and time has shown that visually & functionally it nigh impossible to tell the difference between a prototype and product to non-developers; if it works, it works. The gain is more scaleable code, and shorter timelines to make changes & add features.
After reading Web Development 2.0 from Web-2.0-Propaganda-Central, it seems like a combination of the above techniques is needed to be successful in the ASP model; software as a service.