Some years ago, a Canadian band named The Guess Who (not to be confused with the better known Who) had a song titled, No Time. Recently, three unrelated events occurred that gave me pause and reminded me of the song and doing coding in the real world. (By the way, this is a post that we’d really like to get your comments on and experiences in working with ActionScript 3.0 in the real world.)
The Deadline and Short Life
The first event occurred while talking with an agency that is a heavy user of Flash and ActionScript. During our chat, one of the developers said, “You know, we usually don’t do it right,” referring how they programmed ActionScript in Flash. The comment was right out of the blue, and at the time I briefly wondered what he was talking about. The manager added, “We’ve got deadlines, and they’re going to want new projects almost immediately.” It dawned on me that they were saying when push comes to shove, they had to get paid and nobody wanted to hear excuses about a late project because of some perfectionist quibbling about OOP or design patterns. I asked them, “You want programmers who know how to do it right, though?” and almost in unison, they said, “Of course.”
This particular agency produces both beautiful and functional materials. On top of that, they have a complex relationship with developers, graphic designers, HCI designers, managers, other projects competing for company resources, a budget and of course, clients. So getting a project out the door is not a matter of a developer/designer tucking away in a cozy cubicle and developing a product in a vacuum. As though reading my mind, they added, “We almost never have the same project requirements more than once.” Hence, why spend time on a project when it’s a one-off, and it will be off the shelf after a few months of singing the virtues of a product or service? Why indeed?
The Experienced Developer
In a totally different forum than either the agency or this blog, in the second event an experienced developer pointed out that in Flash, global variables were included for a reason and that Singletons were handy global variables. Knowing this developer as a talented and effective Flash/Flex programmer, his points were in two different directions. One theme was that some not-so-good design patterns, namely the Singleton, were found to be quite useful in Flash/ActionScript. To exclude them would be wasteful and miss an exception to the criticisms leveled at Singletons (by myself and others.)
The other direction of his theme was that we live in a real world of business exigencies, and when the choice is adhering to some grousing about “doing it right” and immediate issues of “getting it done,” that latter wins out. By no means was this an “anti-OOP” or “anti-design pattern” diatribe. Rather, it was the voice of an experienced Flash/Flex developer working in the real world where projects pay the bills.
The Superimposed MVC
The third and final event that led me to this post came from a young developer/designer working in a small agency where PHP was in heavy use. He told me that one day they hired a new lead programmer/manager and he came in with a PHP MVC template and from then on that was going to be used in their projects. Everyone saddled up and off they went using the new MVC template for developing PHP.
I don’t know the details of what the projects were nor how successful they eventually turned out. All I know is that this guy marches in and announces they’re going to be using the MVC in their PHP projects and that was that. Apparently, the projects done under this new model were superior to their previous ones but whether the company’s bottom line improved I cannot say. I can’t even say whether the clients were happier with the projects or whether they were able to get them done more smoothly or with less hassle. I do know that if using the MVC led to missed deadlines or poorly functioning software that the new project manager would be frog marched out the door right on his MVC. However, that didn’t happen.
Perfection versus Excellence
When we think of perfection we often think of excellence. However, the two concepts are very difference. Perfection implies flawlessness. The further we move from a “Hello world” program, the further we move from perfection. For a program to be perfect, it must be done with perfect code, using a perfect language and on top of a perfect operating system, (think Vista) and that’s just not going to happen. Perfection is a paralyzing concept. I’ve known more people who have done little or nothing because they consider themselves perfectionists. Any project they attempt is bound to failure because they can always point out an imperfection. These same clowns are equally vocal at criticizing other’s work. They can point out an imperfection. However, they offer no solution or some untested ideal that they themselves cannot achieve. Perfection is a static concept and adds sludge to problem solving and clear thinking.
Excellence, however, is an evolving concept. A person looks for better ways of doing something just because there might be a better way. The pursuit of excellence is fun. It is an adventure with lots of dead ends, retracing steps, and tons of mistakes. That’s how I look at design patterns and OOP. I don’t know everything about design patterns or OOP, but I know that trying to work through them is a mind adventure that’s hard to top. Were I seeking perfection, I’d have given up long ago. And I wouldn’t have fun. There is no failure in the pursuit of excellence; only more knowledge. Enjoy the ride.
It Ain’t Easy
The first sentence on page 1 of Design Patterns: Elements of Reusable Object-Oriented Sofware by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides is:
Designing object-oriented software is hard, and designing reusable object-oriented software is even harder.
Just in case you missed that point, remember both the fact that OOP and reusable OOP is not for those expecting a quick read or quick fix to their software. If you have read Head First Design Patterns, a fun and lighthearted book, you will know that you need to pay close attention to the details that the Freemans provide to really understand what they’re trying to say. You need to read every chapter and example over and over, and remember it’s fun and lighthearted. (Imagine the author of Design Patterns for Dummies trying to stick within the Dummies framework—the title seems to be an oxymoron. Maybe Design Patterns for Oxymorons would be more appropriate.)
For those of us interested in ActionScript 3.0, besides our book, you’ll find a couple more books on ActionScript 3.0 design patterns, but nothing like the wealth of materials for Java, C++, C# and even Visual Basic and PHP. The Data & Object Factory (DO Factory) site has both abstract and concrete examples for every design pattern in C# and Visual Basic. It is one of many C# sites you can find with a wide variety of examples. Likewise, Java has tons of design pattern examples all written in Java, using Java libraries and special features found in Java but not ActionScript. (The same is true for C# examples.) Of the design patterns sites my favorite is Fluffy Cat where you can find examples for all design patterns in both Java and PHP. The problem with these sites is that they tell you very little about the design pattern or about the relationships between the participants (classes, interfaces) that make up the design pattern.
ActionScript 3.0 Programmers Have to be Tough
Besides the fact that information on design patterns for ActionScript 3.0 is just now getting beyond a trickle, many of the structures in the ECMAScript format leave much to be desired. For me, the lack of an abstract class is often rankling, but I’ve learned to live with it. If an abstract class is provided in the next ActionScript release, I’ll probably overuse it, but for now, it’s possible to create “abstract” classes that can get by with overrides. It’s just one more thing, though, for ActionScript 3.0 programmers.
Another fact of life with many ActionScript 3.0 programmers is that they are not formally educated in computer programming. Most of the agencies that hire ActionScript programmers do not expect a college degree in CS or CE. In a quick review of tech job openings for ActionScript programmers, few had CS/CE requirements and I even found one requiring a degree in Graphic Arts or related field—and this was for an ActionScript position. (Some of the hiring agencies just don’t get it.) However, for the most part there is no perception that ActionScript programmers have to meet the same standards in programming as do typical Java or C++ programmers even through the gap between the two types of programming is narrowing—especially with ActionScript 3.0.
At the same time that they do not require a degree, many of those hiring want OOP experience and even design patterns—including one that listed both MCV and design patterns. So going to work for an agency where ActionScript is required has the requirements that programmers usually obtain in CS/CE programs but for ActionScript programmers they expect (assume?) that these skills are obtained from the few OOP and design pattern resources that are available for ActionScript programmers. That’s why ActionScript programmers have to be tough, resourceful and smart.
Hours of Fun!
This gets back to the agency that said they didn’t necessarily do things right but they wanted their programmers to know how to do it right. It also gets to the point of this post. Learning OOP and design patterns for ActionScript 3.0 is a move in the right direction to seek excellence in programming. However, seeking excellence is more fun on the trip than it is at the destination. Besides, very few employers are going to complain if your OOP or design patterns are not perfect as long as the project is completed on time and performs as required. (No one’s going to look under the hood.) So you’ve got plenty of time to have fun trying to plumb the depths of OOP and design patterns. As you get better and better, soon you’ll be able to look at a project and know an architectural shortcut in the form of a design pattern to get the program done beautifully.
As noted at the beginning of this post, we’d really like to hear of your experiences with different agencies and real world experience regarding these issues. Are OOP or design patterns important to project completion or structure? What about re-usability? Do you find learning about OOP and design patterns fun or onerous?
The No Time for OOP and Design Patterns by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.
Bill Sanders
I’ve found similar experiences in the ActionScript world. I am working on a living (seemingly endless) project that isn’t really for a client but rather it is for the company I work with. The project is meant to get added on to and improved day in and day out, with no tangible end in mind except an awesome user experience.
That said, we have deadlines and bills to pay too. I often find myself strongly desiring to strip away large chunks of the application and redo them using design patters because they are constantly in need of change. However, how am I as a developer going to market completely redoing an application so it will “adapt to change better?”
I guess this is the crux in which we as Flash Platform developers live in. People just want it to look good, perform well, and not throw exceptions. In my own projects, however, excellence is key and design patterns are essential because I know that change is inevitable.
Pursue excellence, use design patterns. Just my two cents.
TK,
That’s an interesting project for your company. Of all projects a ‘living one’ would be most in need of a structure where change is constant.
Thanks for your thoughts,
Bill
I felt a real sense of Deju Vu reading this blog post – replace ActionScript with CFML and it’s just as true. CFML developers are also not generally CS-educated but job ads are increasingly requiring all sorts of OO and framework experience. Further, resources for OO in CFML are even more sparse than for OO in AS3.
I’m going to blog a link to this article so expect to see some feedback from other CFML developers (as well as, I hope, many Flash/Flex developers).
I think we need to remember that Flash falls into a unique category of being a design tool AND a programming tool. Often a designer and developer are the same person. I feel it’s only been within the past year that there has been more segregation between the two.
My experience working in ad agencies has seen that MANY agencies view Flash as a graphic design tool and thus dev-igners have changes dictated to them as if they were graphic designers. I’ve had many arguments with account services and even art directors who simply don’t understand there is code underneath than needs to adapt to any change. I can say from experience it can often be hard to write beautiful loosely coupled code when working to a ‘graphic designers’ timeline.
You’re absolutely right about agencies not requiring formal programming degrees. I have experienced this and can tell you that I believe this is due to AS and Flash being in such high demand that agencies are not in a position to be fussy.
It’s not just ActionScript, I assure you.
The trick is to keep the tech discussions out of the awareness of upper management. If it’s a serious project, good, reusable code is going to be vital to getting it done.
Sometimes you have to split the baby, of course–you know, choose where you’re going to use particular approaches that aren’t clear–but you can get most of the benefit from many of the obvious choices.
Your point about perfection is the key: You’re really trying to minimize the pain of development and especially maintenance.
Paradoxuically, a person with a CS degree is orders of magnitude less likely to ever innovate anything than a person who is self-taught. ;)
My experience with OOP is just there is not much experience with it. The previous company I worked for was rather scared for change to a MVC model for their PHP work (All the Actionscript work was done by me so there was not really a check on my work). Also changing there HTML (tables) output to XHTML and CSS was scary.
The reason was simple, why change a method that works? Instead of thinking that changing the method would increase excellence and decrease flaws.
Convincing people that are happy with their methods is impossible.
The current company I work for uses OOP in all their projects and it really pays off.
Design Patterns and MVC weren’t taught when I was in school for my CS degree, but that was about 10 years ago. OOP was taught, but it wasn’t heavily stressed in terms of design, just the academics of Encapsulation, Data Hiding, and so forth. Given that the vast majority of programmers have some experience under their belt (5-10 years at least), it’s likely that only a small portion of the programmers out there have actually had any sort of formal education in Design Patterns.
I’m not sure what’s being taught today, but I would actually hope that they aren’t teaching Design Patterns. Design Patterns are natural patterns that arise from using good object oriented design principles, but I think that those principles are more valuable to teach than rote patterns. Patterns are “case studies” or maybe shortcuts which allow you to enact the principles without really understanding why you’re doing it.
However, I heartily agree with your discussion of perfection and excellence. Far too often we developers let the the perfect be the enemy of the good. Instead, we just need to be looking ahead, and constantly improving our current “state of the art”. You will often hear experienced developers lament the horrible way that they wrote old code. This is the sign of a good developer. Someone who thinks that their old code is acceptable is not growing, not building their skills.
Mostly agree with the points above.
But “few OOP and design pattern resources that are available for ActionScript programmers”?
I would say that there are plenty of such resources. Starting with the 5 years old classic “OOP w AS” by B. Hall and S. Wan.
As for usage of OOP AS in an agency environment, the practice is good mainly for keeping your own sanity in an environment where shifting goals and requirements are a given.
who innovates or not is not point of any degree, as Einstein and few other fellows had degree you know :), and some others not so …
problem is that most of the agencies are marketing based and that’s it, they only need it done and they are not interested in how. usually nobody is aware how programming can be reusable and so on…
problem when agency decide to move to OOP that not all old fashioned not BS programmers just cannot follow on that and they don’t want to
they should know one thing, in following years, not doing proper programming even for Flash projects will get them out of their jobs surely, cause more and more real programmers are coming into Flash world because it’s interesting and more opportunities are coming
OOP, design patterns and stuff, near perfect code – all sounds great. Don’t forget guys that we’re making websites not deep space probes! Besides even the most elaborate software breaks (see Ariane case). More than once I saw people struggling with CSS, AS3 and homemade content management system just to make a banner displayed for one week … with Subversion on top of it of course. After they left the company another poor people were trying to reuse it. It was hell on earth. This is real life …
Hi Ike and Mr. Steel,
I really don’t think innovation is a function of having a CS/CE degree or not. If I’m not mistaken, I believe Ike meant that CS graduates learn a certain number of things in a certain way. The conclusion was that they tend not to innovate as much as self-taught programmers who don’t know any better. In other respects CS graduates know enough to explore areas that others may not know exist. One area where innovation is rampant is in OOP and design patterns, and CS graduates are more likely to be introduced to these concepts. Both groups have reasons to be innovative.
For me innovation is a function of many different things–attitude and environment being key. One student I know had a summer internship in a government agency and the environment was fairly rigid. The director of Web and computer services had placed narrow strictures on what the different agencies were able to place on the Web. Such strictures certainly stifle innovation.
A programmer, regardless of background, either has a spirit of innovation or not. I have no idea what that spirit or attitude is based on. However, I do believe that the more interaction that programmers have with one another, the more innovation you’ll find.
Cheers,
Bill
I agree with you.
I would say that in all formal programming parts if you know the concepts you don’t need to invent them, but anyway you can and you will distort them to be better for you.
Nice thing with Flash is that innovation is almost everyday thing. Allright :), maybe not innovation but discovering and that’s what I like about it.
Hi Cosmin,
You are quite right that Brendan Hall’s and Sam Wan’s ActionScript OOP book has been available for some time. (It was also very well written and incredibly revealing about certain aspects of Brendan’s life!) In fact, that was before ActionScript 3.0 where we got the tools we now have. My point was not to dismiss some of the great resources we have but rather to point out that they are scarce in comparison to languages like Java, C++ and even C#.
Kindest regards,
Bill
Hi Adam,
Keeping in mind that design patterns were generally introduced to the larger programming community in 1995 with the publication of the GoF book, it’s not surprising that 10 years ago design patterns were not part of a CS curriculum. Many CS/CE departments still do not have design patterns in their curriculum.
However, many CS/CE departments do include design patterns as part of their program. Check out MIT’s course offerings for undergraduates as one example–they also include the lectures and notes! (Another great resource for those interested in DPs.) Here’s a URL to a MIT introductory course that includes design patterns.
My introduction to computer science pre-dated computer science! We were introduced to binary and octal math, computer structures and Fortran II. (And we fought off dinosaurs between classes….)
Cheers,
Bill
My experience has been that trying to collaborate with other Flash developers on any complex application requires we all speak the same language. That usually means a common framework or collection of design patterns we all understand and adhere to.
Bill,
A few times in your post I got the impression that design patterns are language specific. If you intended to communicate that; I would whole-heartedly disagree. Design patterns exist at a much higher level than any specific implementation. And any given design pattern can apply to development issues you’d experience in multiple languages / environments.
[quote]
Are OOP or design patterns important to project completion or structure? What about re-usability? Do you find learning about OOP and design patterns fun or onerous?
[/quote]
I personally think that a good understanding of encapsulation principles is more important to the reusability of a project than OOP or design pattern usage. Of course, if you have a good understanding of encapsulation, then it’ll be easier to understand OOP or design patterns.
Good encapsulation principles are important to the long term maintenance of a project; however I would say they make things take longer in the initial development. Such decisions must be balanced based on priorities of a project. Sometimes the schedule is more important than maintainability.
In the ColdFusion Community, there is often a general assumption that OOP is good, but Procedural programming is doomed for failure. I attribute this to the fact that most CF Developer’s do not have degrees. I think a procedural implementation that focuses on good encapsulation principles will have much more success than an OOP attempt that does not follow such rules.
Ike said
[quote]a person with a CS degree is orders of magnitude less likely to ever innovate anything than a person who is self-taught. ”
[/quote]
I disagree w/ that statement completely; but would love to see some stats / studies on that. I tend to think that a good education will drive people to want to learn more and that will lead the “educated” to innovate more. However, I’m willing to bet there are plenty of people (with or without education) who can be declared innovators.
My experience is that many people programming do not have a college education in Computer Science [or Information Systems; or whatever the college call their programming curriculum].
Adam Ness said:
[Quote]
Design Patterns and MVC weren’t taught when I was in school for my CS degree, but that was about 10 years ago. OOP was taught, but it wasn’t heavily stressed in terms of design, just the academics of Encapsulation, Data Hiding, and so forth.
[/quote]
Sounds like Adam had a very similar education to the one I had. Quite frankly, I’m not sure this is a bad thing. I would expect all good programming curriculum to start with a solid–ideally language agnostic–grounding in encapsulation principles.
At the end of the day, my consulting priority is fulfilling the clients requirements in their timeframe and within their budget. Sometimes that allows for a more complicated architecture or code refactor. Sometimes it needs to be done quick.
Hi Jeffry,
Your impression that I was suggesting that design patterns were language-specific is mistaken. When I pointed out that trying to get a design pattern to work in Flash/Flex with ActionScript 3.0 can be difficult because one often has to look at prior DP examples, I was describing what happens when you examine a DP in a different language. Most of the examples are written in something other than ActionScript and these examples often use libraries, statements or structures not available in ActionScript.
Bill
Paradoxuically, a person who is self-taught is orders of magnitude more likely to constantly reinvent the wheel than a person with a CS degree.
Bill,
Actually, I believe that many Design Patterns really are language specific. There are a few exceptions, but even many of the common, simple ones truly are language specific. The Singleton pattern is actually a design choice that many people use to overcome a limitation of the Java Runtime. Move to a different runtime, like ActionScript or Microsoft CLR, and singletons become less useful, or take on a very different role. Even in ColdFusion, which runs on the same runtime as Java, Singletons take on a very different role.
Or take a look at the Iterator pattern. There are certain runtime and library optimizations that make the Iterator patern work exceptionally well in Java, but in C#, ActionScript, or ColdFusion, the design pattern falls apart. You can wedge the language into an Iterator if you really try, but you’re actually better off using similar, but different different patterns in those languages.
For ActionScript developers, examining Java, C#, or ColdFusion design patterns is useful, because it gives you case studies in the OOP Design Principles, but there’s a severe risk that inexperienced developers will take those design patterns and attempt to implement them directly in ActionScript without understanding the differences.
I’d argue if CS is really the right place to categorize this. Maybe SE, but the part of CS that relates to actually writing software in the first place is very very small. CS and CE are not about computer programming.
CS is mostly (discrete) math, algorithms, and complexity theory. As the saying goes, “CS has about as much to do with computers as astronomy does with telescopes.”
If you look at most Universities with respected CS programs there may be one Software Engineering class that mentions design patterns, and there may be a few name drops of them in low level programming classes, but rarely is it the focus anywhere.
The issue is that the very concept of design patterns is deeply rooted in practical thinking about how to write software. While theoretical, the patterns solve, in general, issues presented in actually writing a full piece of software. And in many cases they solve issues presented by the language chosen, and don’t even relate to the greater whole of software development.
MVC may be a big deal in desktop and web application development, but as far as CS is concerned it’s a minute and generally insignificant part of the big picture.
This is not to say that design patterns don’t have merit and certainly not to say that they don’t (help) solve problems, but claiming that CS people somehow should know design patterns seems fairly ridiculous.
Hi Adam,
Design patterns may have to be built differently depending on a language’s structure, but the patterns were not developed to be language specific. Design patterns came along before ActionScript 3.0 and have been effectively adapted by ActionScript programmers. I also believe that future languages will be able to adopt them as well.
By the same token, just as procedural programming replaced sequential programming and OOP replaced procedural programming, I have no doubt that some bright light will develop an alternative to OOP and design patterns. For now, though, I tend to think of design patterns to be a general set of solutions that can be applied to any language, albeit with different implementations depending on the language’s features.
Bill
Elliot,
For the last several years I’ve attended the OOPSLA conferences, and every year I meet with programmers from all over the world in CS programs who are working on ways to best present design patterns to their students. I’m not talking about a few elite programs like MIT’s (who include design patterns in their curriculum) but rather programs from every stripe. They represent every major language taught in universities everywhere and thousands of CS majors.
So while it may seem fairly ridiculous to you that CS people should somehow know design patterns, it doesn’t to the CS people who are responsible for educating the next generation of programmers.
Bill
thanks for the article. when you were explaining your conversation with the agency (heavy user of flash/as) it made me think of the agency i work in and my/our approach to each project. while i _wish_ i could spend as much time as i wanted to on any given project, i am totally aware of the looming (and often unrealistic) deadlines thrown over the fence. that being said, i don’t know that any deadline really “dissuades” me from OOP per se, but deadlines definitely cramp my “creativity” if you will.
to me, programming is similar to art … if i’m the artist, is it your job to tell me what brush i should use? are you going to dictate my choice of colors? the medium on which i will paint? i’m sure most would agree that these are decisions best left to the artist.
unfortunately, real world projects tend to make me feel more like the guy on the beach airbrushing t-shirts for $5 each. sure, i’ve got a little freedom, and the client doesn’t care what “technique” i use, just as long as they get their airbrushed t-shirt, it fits and looks half-way decent.
Hi Steve,
The guy on the beach airbrushing t-shirts is a perfect analogy. He goes to Art School for four years studying anything from fine art to computer graphics and ends up doing what he has to do to make a living. Even worse, on his own time he creates an artistically complex but gorgeous screen and takes it to work to show his boss. The boss says, “Yeah, that’s nice, but the smiley faces with a bullet hole are selling…”
Right now I’m working on an idea that might be helpful for taking a design pattern to work. However, I have to finish up my article on the Interpreter design pattern first.
Thanks,
Bill
I have to echo Ike’s sentiment. I haven’t a Computer Science degree and feel quite liberated by that fact. I have worked with plenty of “seasoned pros w/ CS degrees” who were utterly at a loss to innovate and or (not to over use this cliche´ term) “think outside of the box”.
As to the argument of perfection and excellence, I am somewhat obsessive-compulsive regarding programming and code. I often find myself spending time on tab indentations or reformatting someone else’s bracket formats and spacing. All for what? It doesn’t make the code run any better. When I get this way I have to repeat the following matra to myself in order to break free from the OCD:
perfection is the enemy of completion
Great article, thanks for the good read.
People who work at ad agencies aren’t going to be re-reading their code in two weeks, or checking it into SVN. They have deadlines which most closely resemble “can we have it by the end of the day”.
That means start hacking and slashing and slopping up the scrambled eggs like a short-order cook.
It also means cozying up to the idea of working inside sprawling, code-littered timelines, weird .as files which never find their way inside a “com” folder, and creating animations in the library of type “Graphic” as opposed to a MovieClip. Took me a million years to figure out why in christ’s name anyone would ever need to do that.
Thinking about sending your wicked awesome CS4/AS3 Flash banner to the publishing bureau for world-wide distribution? Guess again: they’re wrapping your precious work inside a .swf made with Flash MX 2004. Your URLRequest() doesn’t work with their getURL() clickTAG, and their spec from 2002 offers you sample code containing the phrase “tellTarget”.
I love all my AS3 design pattern books. Pity I never get to use them in the real world.
Hi TF,
You know, in a few short years, pre-ActionScript 3.0 apps are going to be so dated that there may be a chance to start sneaking in good code and good structures. I’m working on a new post, “Take a Design Pattern to Work” and I have a plan using Guerrilla coding to bring in better ActionScript. (BTW, in a job application for a Flash position recently, they had questions about some pretty dated code and are still looking for ActionScript 2.0 programmers.)
Your comments were spot on. Thank you for them.
Bill
I really enjoyed this article and have pondered this same issue countless times. I agree that the more knowledge and understanding one has of MVC- the faster and more efficient one can become at implementing time-saving solutions to projects.
Hi Jonathan,
That’s a good point. Developers face the ironic situation of not being allowed to create an architecture that would in fact make development quicker, smoother and more efficient. Instead they scramble to get something out the door that’s more likely to be a bagful of problems. However, because of rapid turnover, no one notices or particularly cares–the junk they create has no consequences. Maybe your FlashMVC is part of the solution.
Bill
This is a great article. So much truth was spoken here. I really enjoyed the topics of Perfection vs Excellence. I can relate to this article in so many ways it’s uncanny. Everyday I deal with situations where there it seems there is no time to do things the right way. I am grateful for resources such as this because I am one of those hybrid types thats expected to design and to program. Fortunately I love to learn. Thanks again!
There’s one institutional fact that has nothing to do with languages, devigners or OOP, but does impact Flash development directly.
The entertainment, ad and media companies that employ Flash developers have money to burn. The metrics on their ROI are often hazy, and software development is fairly new to them. So they have pretty low standards.
In fact a LOT of their development IS long-term and evolving, and not just ad banners. It would benefit hugely from better programming. But management has to demand it and respect it, and they won’t until they really feel the pinch.
Matt
Hi Matt,
I am very glad you brought up the point that a lot of web development for media companies is long-term. The fact of the matter is that those who should be aware of it have neither the background to understand it nor the motivation to plan for long range development. It’s almost random when a good structure is introduced into company programming model that helps the company to achieve a competitive edge.
Good to hear from a fellow UCSB alum,
Bill
In my opinion, if time permits, the goal is to be as purist as possible. That’s why I prefer to work with those that have OOP and design pattern skills, because if they’re good enough, coding with design patterns is subconscious, they don’t have to think about using singletons, delegates, mvcs, or any other design pattern. It’s automatic for them and they code just as fast. It’s the developer that’s unaware of these terms that’s going to be the most inefficient and a risk to the success of the project.
Planning always helps, but if the project is a low budget, short deadline, never going to get changed, with a short 6 months to a year lifespan, then the client probably has a “get it done” over “oop & design perfection” state of mind. I always give the client options of what workflow they want to take, so (s)he is aware of the consequences, and can rethink the budget, scope and deadline. Sometimes the “get it done quick” is a better option, it depends on the variables.
Like a doctor, you can always advise your patients of the better choice and the risks of taking the bad choice, but at the end of the day it’s up to them, as long as they are aware of what they’re getting in to. If it’s something that you know is going to fail then it’s best not to take the project. For me, producing something of great quality is better and more rewarding than making money off a failed concept.
We recently ported a large Java project to Flash and I’ve thought a lot about how ActionScript has imposed some issues with our original design. I wrote up a series of posts about the port and the issues we came across, the first of which can be found here: http://blog.sharendipity.com/were-moving-to-flash-heres-why. Subsequent posts describe in depth the problems we came across.
What I’m interested in is a related question: When does the user experience require that you deviate from your design principles? Ultimately, the user experience is what we really care about. The underlying design would ideally facilitate a better user experience, but I don’t think that’s always possible.
I don’t necessarily think that we’ve sacrificed our core design along the way but we certainly had to spend a lot of time fixing things that were a lot easier in Java. Examples are our original use of the adapter pattern which was based on the Proxy class in ActionScript (now changed to inner classes using namespaces), implementing pseudo-threading for hierarchical tasks, scoping of anonymous functions, and several problems that arose because of the lack of abstract classes and other language differences.
Psuedo-threading is an example of where I would have liked to avoid injecting dependencies for a pseudo-threading manager throughout a lot of our core code. Here, I had to break some of our encapsulation in order to achieve a desired result. In that respect, it’s really a combination of the need for a fluid user experience combined with a language that doesn’t support certain operations that required changing our design. I’m curious if anyone else has come across an issue such as this where the user experience drove a result that wasn’t desirable from a design perspective.
Hi Nir,
I really like your idea..
While you may not be able to spend time in the middle of a busy deadline to sharpen your OOP and design pattern skills, at some point they become a natural part of doing coding. Poor coding is the same; if you do it long enough, it becomes part of you. I’d rather try and improve all the time!
Kindest regards,
Bill
Hi Dale,
Coming from Java, ActionScript 3.0 imposes certain restrictions (or workarounds, or whatever). This is especially true if you know Java quite well but you’re just getting used to ActionScript. The more you become familiar with ActionScript, I would imagine you’ll find both more restrictions and some nice Easter eggs as well.
Your blog on moving into ActionScript from Java is great, and I plan to read more of it carefully.
Kindest regards,
Bill
Money is not that important. We have so much technology that we should all be relaxing while machines do the work for us. The need to be stressed out and continually produce more and more is a lie perpetrated by greedy capitalists who believe in slavery to their systems of authority.
What is the point of life without art and beauty? What is the point of life if all you produce is one ugly design after another just to keep waking up in the morning, feeding your belly, and dumping it out the next day? There is no point in that.
Hi Matthew,
While I don’t think there were too many political considerations behind OOP and design patterns, I do believe that there were economic ones. A lot of people were trying to figure out what practices worked best for good OOP, and they developed many of those we’ve discussed on this blog in the “Lunch Bucket Rules” series.
Erich Gamma was working on his doctorate in Switzerland and took as his topic a set of patterns that would adhere to good OOP and solve a lot of common problems that programmers encountered. If you look at the OOPSLA meetings up to and after the publication of Design Patterns by the Gang of Four, you will see a good deal of discussions about re-usable and easy-to-update and change programming code. The idea was that if certain practices were followed that changing and updating code would be made easier. This would save money wasted either in re-writing hacks or starting from scratch with each new project. At the same time, the solutions they came up with were quite elegant in the reasoning behind them.
As far as relaxing “while machines do the work,” you’ve got to remember that we’re the ones who tell the machines what to do! Programming will also be a mix of invention and creation mixed in with drudgery; just like most other jobs. However, as an “art form” it can be quite rewarding–as you seem to be saying.
Take care,
Bill
As a ‘new generation’ programmer (I’m currently in my last year of CS) I really notice the difference between the “old skool” programmers and the new generation of OOP and Design Pattern based programmers. During my education we actually get lessons in design patterns, however we don’t learn specific design patterns, but we are encouraged to solve problems in creative, reusable ways. In some projects the actual target of the project was to force us to adapt to rapid change (but of course only the teachers knew that, we just had to do a big project and the teachers kept on changing things along the way), making the use of good OOP and DP an important part of the design.
During my 4 year study I’ve gathered quite a library of classes (most of them DPs) making my life as a programmer a lot easier! Good going for my school, I guess, but I agree to the discussion that in real life the “get it done yesterday” part more often than not wins from doing things right.
Great blog btw! Keep up the good work :)
Hi Thomas,
The workplace is a funny thing. Design patterns were created originally for the workplace, but we find that in some workplaces that no one has time for DP. I think that your institution is exactly right in helping you develop practices that focus on reusable code, whether they call them design patterns or not. Likewise, creating a library of solutions means that you’re going to work with a set of practical tools for getting things done that can be reused.
In working through the different principles in the Lunch Bucket Rules series, I’ve come more and more to see them as design pattern templates. My hope is that by thinking about programming through the lens of programming principles, ActionScript 3.0 programmers will eventually use them as a way to get something done quickly. The next time the same issue comes up, the reusable code is sitting there awaiting them.
Even throwing together a hack for a quick solution, one can find eventually that hacks keep getting better and better until one day they are no longer hacks!
Cheers,
Bill