Software, Fitness, and Gaming – Jesse Warden

Category: Business Process

  • Invoices Suck

    Writing technical blog entries has the requirement of something relevant, can be digested in one or two readings, and is well thought out & proofread. I currently have tons of relevant stuff that can easily be digested by the community, but no time to collect my data & write them. I’ve been so overwhelmed with work, that taking the time, even with a gallivant into the South Caroline mountains to stave off burnout, has been hard to find. Thus, I figured I’d report on my current and past situations in an effort to provide corroboration for others in similar situations for the mere sake of relating, or going, “Damn, I’ve got it good.”

    I’ve been contracting with a new company for 3 weeks now, and have officially entered my first Enterprise project. I was under the impression I had in the past, but a few key ingredients were missing, namely more than 1 client developer, and a code-base older than 6 months. I’ve also met my first, successful purist developer, my boss. More on him later, but suffice it to say, he’s apparently successful and follows best coding practices at the same time which is the first time I’ve seen it actually in a real person. He enforces them with a heavy, but well tact hand upon my fellow developers, me included. This is a big deal because I always figured OOP, MVC, design patterns, coding & commenting standards, etc. were just ivory tower concepts that you attempted to implement to help stave off the insanity that software usually is.

    Yet, I’ve spent everyday for the past 3 weeks “cleaning” my code in some way, even if it’s no more than 30 seconds worth. I’ve done more re-factoring & encapsulation in the last 3 weeks than I’ve done in 4 months on most projects. My inference on the logic of such aggressive following of best practices, aside from what I’ve been told & discussed is that of confirming my own experiences. For example, it took me about 5 years to really feel like I knew wtf I was doing in regards to programming. Yeah, you always learn, but there comes a point when all of the stuff you’ve researched and learned finally reaches a point where you don’t hate your code at the end of the day… only after a year. That’s still a great improvement and wonderful pinnacle (plateau?) to reach. In that time, I’ve learned how valuable OOP, MVC, and Frameworks are to fighting off scope creep, reducing the amount of code you have to write, and making things easier to maintain over time. This has NOT been the case with code-formatting & naming standards, nor with commenting rules.

    Since the scope of Enterprise projects is soo much larger, my guess is… bigger Godzilla, bigger artillery.

    However, I’m still in like… month 3 of 5 years when it comes to managing business stuff. Take invoices for example. I still have 1 outstanding, and it’s taken me a month just to get 4 out of the door. And, #4 of 5 yesterday accidentally had a factor of 8 hour days instead of hourly on it… but I put hours on it. This was like almost 5k extra I was charging the client. Thirty minutes go by, and when doing something time related (I’ve been doing a crap-load of time tracking lately as well), I suddenly realized the invoice I did was based on a different time scale and immediately called the client, explained the error, and re-sent them a new one. Oops… what an f’n crackhead.

    In reading the Pragmmatic Programmer, and realizing every Flash Game programmer that is good uses emacs. As such, I’ve been trying my damndest to get lower level, to use command line and other automation tools that have been around forever. The goal is to further expedite my development and work to make me more efficient.

    …therefore, I’m wondering wtf people do for my invoices. I had a weeklong drama talking to my dad about secretaries, and what they entail, etc. He uses Quicken to do most of his paper work, but it didn’t do his service work sheets, so he’s actually buying a custom product to help run that + expenses + keep track of his service work.

    For me, it’s merely I did X in Y time, please pay this amount, thank you, your project was fun, hope it makes you bling, have a nice day all in Excel. Writing these things and keeping track of them as well as who I sent them too, and who sent a check is… well, it sucks. I’d rather be coding vs. running the mundane business details via Excel & Outlook. What do people usually use? The same method? Do they have a Administrative Assistant do it? Or, should I shut the $)%* up and bite the bullet?

  • Prototype Solutions

    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.

  • Flex & Agile Software Development

    I took a stab at Agile Software Development on my latest Flex project. I haven’t read much on Agile Software Development. I really didn’t have to. Many blogs I read pretty much summarized it into “weekly builds”. Those 2 words don’t do it justice, but they certainly imply the “release early, release often” mentality. This greatly changes the way I’m used to doing things.

    First, I’m used to coding a bunch of classes; compiling them to ensure my ideas work. If they do, then I start building an architecture of code I’ll learn to live with, start bringing in the ARP classes, and building my Views first since View’s are easy, and pretty much drive HOW you use the app. From there, it’s building Commands that equate to “doing” things, and finally the dreaded Delegates. They contain all your server methods, data mangling… er, I mean handling, and call your back-end via Remoting (CFC’s, PHP methods, Java methods, etc.). Finally, you start wiring things together… and do your first big compile.

    All of that crap above usually equates to a 2 weeks to a month. You don’t ever really see your software taking shape until you get true data coming in from the back-end.

    Not with ASD.

    Instead, every week, I complete some milestone through a series of goals. By Friday, you can not only compile, see your targeted functionality working, (damn this is a good mix, rave, rave, rave…), but you can more quickly tell if the functionality is “right”. Meaning, you can throw it in front of a user or your client, and go “What do you think?”. Suddenly, that’s one less thing to worry about prioritizing. You either were madly successfully, or screwed up big time. Screwing up early on the main functionality is fantastic! You can more quickly make it right, when it matters most. You can either wax the functionality, mark it off on your list as done, or tweak it next week.

    The trade-off? You have to write code that compiles. Suck. I know, right? Writing code that compiles… imagine that. Seriously, though, you can flesh a TON of stuff out, and more easily see your designed masterpiece more quickly and easily if you pretty much tell the compiler required code to f’off for a few days/weeks while you flesh out your ideas. Getting something compile-able, especially in a larger project even with a framework takes a lot of finishing touches, final nuts and bolts details to be written, and overall a lot of duct-tape that is a pain in the ass to write.

    Granted, it doesn’t take all of that long to write, but it is very volatile code, doesn’t flow from your fingers, and you are definitely not emotionally attached to it. After all, it is not what makes your architecture a masterpiece… it just allows the compiler to understand it. Examples include THE import statement that runs attachMovie on your main component, or the code that throws fake data at your view to show it’s working… crap like that that is usually a lot more involved and larger in scope that what you use to initially test. All of that to compile.

    Again, however, the results are well worth it. You suddenly aren’t recoding functionality milestones. You very quickly know whether or not they hold up in terms of being useful to the user, or liked by the client. They are done. The d-word is the hardest thing to say in software development. Seriously, how many times have you cheapened that word’s meaning by saying it so many times, thinking that if you repeat it like Dorthy repeated being home, that it would actually manifest its details and happen.

    So, seriously, you’re done… and if your not, you know usually exactly what NEEDS to be done to make it so. Good feeling.

    The down-side, is, someone either needs to update the wire frames after doing the iterative sweep, unless it’s a minor tweek, or there aren’t many developers involved.

    The other benefit, at least I thought, was “proof of progress”. As I recently told someone via email advice, design projects are more subjective & visual, thus visual changes delivered via a calm, positive voice imply progress. You do the same thing with 50,000 lines of brand new code, but no one gives a shit if nothing changed visually. With a working build, however, you can clearly click the same button 50 times and go, “SEE!!! A new error alert comes up; I worked all weekend for that error checking… my alert dialogue will p@wn you client! IT’S MODAL… IT MUST BE OBEYED!”

    Since code, while objective to track, is subjective to show, it suddenly becomes more objective; you can clearly show something working that wasn’t working last week. The cool thing, too is that ALL of your other stuff usually doesn’t break. Why would it? You’re already “done” with it. See where this is going?

    However, I’ve found in practice this didn’t hold up. nTier development usually consists of a server that doens’t truly work without a client, and a client that doesn’t truly work without a server. Both have to be developed to their extent, and tested in concert.

    Regardless, weekly builds, while not getting the proof of progress emotional effect I wanted, clearly smoothed communication between my boss and I. We can waaaaaaay more easily judge what was completed, what wasn’t, and where we needed to go specifically. Anything that helps communication in software is a good thing!

    So, in conclusion, while it was hard writing code that was compile-able more early than I’m used to, as well as ensuring it compiled every week to working state to ensure a feature did in fact work as the client intended, it was REALLY nice to never touch a specific command, delegate, and view (mvc basically) again, unless something needed to be changed because of scope creep or it needed to be changed because it was looked at the very same day. That made me feel like I was actually making progress.

    I think a lot of developers feel like they coded something, only to write 10,000 lines of code that equate to 100; since they’ve written that many lines just to change the same 100 through the course of a project’s lifecycle.

    Second, while perceived progress didn’t give the emotional effect I wanted, it certainly made me feel good about how the project was going, and helped communication with my boss.

    Finally, it was a lot easier to project time-frames; I knew what was truly “done” so could clear my mind of other concerns when calculating timeframes of what needed to be done for the next milestone.

    I guess I was under the impression that ASD would give my clients a warm feeling that we were truly making progress because they could “see it working” but that is a false perception. Live and learn. It’s really for me, the developer, to be more successful, not to make people feel good. Bottom line, I’m successful when my software is done.

    So, where does Flex fit into this? This is the first project where less than 10% of my problems where related to the tool I’m using to complete my task. The rest were coding & testing errors on my part. This 10% included undocumented lower level classes dealing with the Flex framework, lack of true strict typing to catch misspellings resulting from more dynamic ways of coding, and extra time that it took to debug using FlexBuilder.

    My experience in the past has been 30 to 40% when dealing with Flash. That portion of your time is figuring out “wtf Flash is doing” vs. “wtf is my code doing”; which a lot of time one blurs into the other, mainly in regards to use of components.

    This time, however, Flex came through and I felt like I had very little problems when doing this project from a coding standpoint. The only problems I DID have were communication wise, and that’s pretty good considering I telecommute.

    I think I’ll use Agile Software Development on every project from now on, from big to small in scope. It feels like I’m building pretty prototypes, and I have the option to use the word “beta” in a pinch during client/user testing. Overall getting more done, and getting it done better. I know for damn sure I’ll be using Flex; she came through like I expected her to.

    …this assumes my definition of what Agile Software Development is, let alone my implementation, is even accurate. Even if it’s not, it’s certainly better compared to “the big compile”.

  • Financially Justifying Speaking at Conferences

    Flash conferences are fun. WebDU (formerly MXDU) is fun because you have an international crowd & speakers, it’s in a warm climate in an awesome country, Australia. I’ve heard great things about Flash in the Can, Flash Forward, and MAX. I was planning on speaking at Flash in the Can & Flash Forward in 2006… but plans have changed.

    Not only have I waited too long to submit proposals, but I suddenly am finding it hard to financially justify speaking in the first place.

    Why do I speak? I love to speak about what I love, and what I love is the technology I use, namely Flash and its brethren. I also love meeting people I’ve known online for years, but never met in person. I enjoy seeing those I have already met, and hanging out again.

    I cannot, however, justify them financially anymore. Now that I’m a contractor, even if travel & accommodations is paid, that is still time I am not working, and thus making no money. The first 2 MXDU’s did wonders as additions to my resume, while the networking contacts went deeper than business. Capitalizing on them seems fruitless, however. My plans to relocate to Australia never panned out, so I’m apparently in the states for good.

    All of the potential work I receive is through networking contacts, my blog’s high page rank, and referrals. No one has specifically mentioned they heard me speak at MXDU and want me for a project. While many assumed I’d be at MAX, most were friends & professional colleagues.

    I know a lot of people who are speaking, some personally, and I guess I really don’t understand how you all financially justify speaking at them. It’s easy to emotionally justify them; they are extremely fun and rewarding, and sometimes you even learn something during chats, or the odd chance you’re a speaker and actually attend a session.

    Obviously, this point is moot if you are an attendee; I’m referring specifically to speakers.

    If you are a speaker, not an attendee, how do you financially justify it?