The Flash community is very diverse - it is a mixture of designers (UI/UX/IA), solid software engineers, artists, technology enthusiasts and a great number of individuals applying multi-discipline skills on various levels of fluency. It’s been a vibrant, extremely creative community that drove most of the innovation of the UI/UX for the web. For the last 15 years Flash grew from just an animation tool to a fully-fledged enterprise application platform, but unfortunately the majority of Flash users could not grasp the meaning and implications of such a shift. Because it is not just shift in technology, but rather shift in the attitude - of what kind of products can be built-on Flash, of what kind of scale and complexity can be tackled with it, and probably most importantly what kind of professionalism is required to built software products of this completely different magnitude.
It is clear that still the majority of Flash users are the creative community. This community can be characterized mostly with its tendency to focus on what’s getting build and giving little or no attention at all on how it is getting build. And I believe this is how it should be - designers should stick to design work and concentrate on the vision for the software product, while engineers should worry how the vision is going to be implemented. Sadly, this division of labor keeps being denied by the creative community as it continues to produce “awesome coolness” with suspicious engineering qualities.
To make such technological shift to work Adobe aimed at attracting more and more software engineers to the Flash community, but it appears it was at the cost of blocking non-programmers from building the things that used to be build easily from people with no computer science background. There’s an ongoing effort of bridging this gap between designers and developers, but while this hasn’t happened yet as my friend-designer Fabian Vercuiel has wisely put it: “It leaves the members of the creative community in some sort of an identity crisis“.
People start asking: “What am I? Am I a designer or a programmer?”, and it’s a common thing to see one-guy-do-it-all in a Flash software project and running into bios similar to: “Artist, Designer and Technologist”.
This is a huge problem and I’ll tell you why!
In the past the one-guy-do-it-all approach worked well, because the projects were predominantly small, didn’t expect extensions and didn’t require long-term maintenance. So it was affordable not to pay attention on how they’re getting built - quick & dirty cowboy programming delivered fast results and clients were happy.
With time projects grew in size and complexity, but the attitude towards building stuff stayed the same - things are still getting built with no respect to the underlying software architecture and with total ignorance for the need to put some extra effort to maintain the cleanliness of the code.
Creative technologists continue to undertake projects they could not handle properly - as the “awesome coolness” get bigger and bigger in extremely short periods of time this might amaze the client for a short while with its astonishing productivity until it reaches that certain moment where the creative technologist could not proceed further - simply because what’s being build even though impressive with its UI/UX is nothing but a mess. After reaching this point the client comes to the realization that the project is going nowhere and the total cost of owning a mess is zero productivity. If smart enough the client goes to the software engineers and hands off the work to them. And here comes the ugly part…
The software engineers are in a position in which they have to convince the client that the only way to proceed further is by doing a complete rework. But the rework usually takes at least twice the time spent by the creative technologist. From the client’s perspective this is unacceptable - it’s because the product has already been demoed in some level of completeness and because it is a work the client already payed for. Even if the software engineers manage to convince the client to rework, inevitably their productivity is going to be compared to the productivity demonstrated by the creative technologist. All this is unfavorable for both the client and the software team and it brings immense stress to such projects.
I see an easy resolution that will avoid such situations to happen and it is based on simple honesty.
As a creative technologist you are obliged to inform your clients that:
You have a low level of proficiency in the software engineering craft, unless you’re really a professional software engineer.
You’ll produce a beautiful demo that will eventually need a major rework, unless you’re really a professional software engineer. Software engineers refer to such beautiful demos with the term throwaway prototype denoting that this is a conscious decision to produce something quick & dirty in order to reduce various risks for the project - either design-related or technology-related risks before proceeding with the production of the actual solution.
To all creative technologists that want to move to the next level of their software engineering proficiency I’m recommending them to get educated on the following subjects:
Design Patterns and OOP in general
A classic book on the topic is Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John M. Vlissides
Software Architecture in general
A classic book on the topic is Software architecture in practice by Len Bass, Paul Clements, Rick Kazman
Writing clean code
I especially recommend Uncle Bob’s book Clean Code: A Handbook of Agile Software Craftsmanship
8 Comments
Theres another problem: hierarchy. I’ve worked with a large developer team and I experienced the problem of hierarchy. Leading a horde of software engeneers can be exhausting, especially because it needs one designer to tell five programmers what they have to do. it’s easier to do it on your own sometimes, instead of calling in meetings and communicating until the wire gets hot.
Really, really good article. Thanks for the honesty - it needs to be said.
I have openly developed throwaway prototypes - for phone software and TV set-top-box programme guides. To be honest I’d apply the same TDD/BDD, frameworked approach to those now, but at the time the hacking approach was ok.
Jesse Warden talks about technical debt a lot. This is the key thing that I think flash devs often fail to appreciate. There are projects where it’s fine to be technically bankrupt at the end because there was never any intent to go further.
Then there are projects where the client believes they are making a long term investment - and we have a responsibility to not rack up enormous technical debt in getting to the ‘prototype’ stage.
The difficulty is that doing it the wrong way, you look 80% done at the 20% stage. Doing it the right way it’s almost the reverse. Most of my flash buddies who I’m trying to bring on to the software engineering, TDD bus are unable to push past the loss they feel when it doesn’t ‘look’ 80% done early on. They are addicted to that fast and loose development curve, even though it hits a dead end on decent size projects.
We build enterprise apps now - training platform + content. It’s incredibly satisfying to work on chunky projects that don’t turn in to a horrible mess (and I have robotlegs and asunit to thank for that).
My typical-flash-dev friends argue that their clients simply won’t pay for things to be done with TDD and so on. I believe this is because they haven’t told the clients the contents of your box outs. Unfortunately the flash-purchasing industry, mostly agencies, are also hooked on the current model of turning out beautiful but brittle flash projects that are a nightmare to amend later. It’s the reason we’ve made a decision never to work with agencies again!
Very well put and outlines problems that persist for the last 10 years. The entire “web” industry has these problems.
You could have also titled this post: “What’s right with…” and argued that its a positive step to see many artistic types buckling down to learn hardcore computer science methodologies [great book recommendations!] that apply to both Flash and Javascript.
Creative Technologies still wish to make cool things quickly and will cut corners to make that happen to demonstrate complex UI ideas. But many also wish to continue to working on the product — the real build — alongside non-creative programmers who tend not to push UI.
With the proper guidance from a lead architect, a Creative Technologist can rock out the views and achieve the same wow factor that they got from their quick and dirty prototype. In fact, they’ll probably improve upon it taking it to the next level while discovering and correcting design flaws along the way.
CTs are born creative and can always learn to be better programmers if they are willing to commit to it.
You see, Brandon, I’m still not sure that’s a right thing to do… to get creative technologists involved in the software engineering. I just can’t get rid of the feeling that it is going to be such a waste of creative power to use a creative technologist to write unit tests, to constantly spend extra time in code reviews, code refinements and all this engineering and code-related stuff.
You gotta agree that this is a bit ridiculous to expect the designer to take part of the actual manufacturing of the product - to really grasp how ridiculous such situation is you just have to imagine Jonathan Ive (the chief industrial designer for Apple) sitting there in the factory putting together an iPhone.
To my understanding creative technologists are designers that posses the ability to very quickly visualize or I should say materialize their design ideas - and I believe they should really stick to this with the clear awareness that whatever they materialize it won’t have the required engineering properties that would turn it into a final product.
On the other hand I’m not against and I see nothing wrong in that creative technologists are interested in programming. I’m just saying that if the creative technologist is the one who builds the product for the client, then it is mandatory to take the responsibility and execute the whole construction in a very professional manner, just as a software engineer would do it.
@leerraum Of course working in a team means some communication overhead, but there are certain techniques which allow programmers and designers to work in parallel.
Such techniques are:
- using a designer-developer contract - before starting the development you prepare a contract - usually the contract specifies which are the required and optional parts of a components, which are the states, custom styles, etc. And then the programmer can work on the implementation of the logic, while the designer could prepare the skin (which is basically a markup with components, states and transition between states). The Spark components in Flex 4 support such model of development
- having a custom implementation of the ‘Passive View’-pattern
It’s easier to do by yourself just prototypes of limited scope and complexity, but when it comes to dealing with industrial strength software it is simply impossible to be handled by a single individual.
I’ll end up with a quote:
“The distinguishing characteristic of industrial-strength software is that it is intensely difficult, if not impossible, for the individual developer to comprehend all the subtleties of its design. Stated in blunt terms, the complexity of such systems exceeds the human intellectual capacity. Alas, this complexity we speak of seems to be an essential property of all large software systems. By essential we mean that we may master this complexity, but we can never make it go away.”
“Object-Oriented Analysis and Design with Applications” by Grady Booch
As an Actionscript developer from Flex 2 in 2006 to an experienced Flash Builder 4 developer that learned Photoshop to use Catalyst in 2010.
Adobe changed my workflow completely from JS.
Incoming Links
Leave a Reply