The Waterfall model has become the whipping boy of 20th century software development.  The idea that analysis, development, and testing are separate, distinct phases of a development project, where time must be allocated to each, and one must be completed before the next begins, is history.  Although it was seldom actually practiced, with time and budget constraints compressing schedules and steps, it was often an ideal to shoot for.  There was some integrity in it, as I recall.  For a long time, we regarded the model as a sign of care and craftmanship.  Unfortunately, this approach made it easier for a company to head in the wrong direction for too long, masking problems in the development process until it was too late to fix them.   It could also squander resources on software that, upon completion, was functional but irrelevant to the market and it’s users.

The era of quick turnaround is now upon us.  It’s harbingers include Agile, Scrum, and Continuous Integration and Deployment.  The terms are new, “stories” and “points” instead of requirements and estimates, but the aim is the same:  produce software products as quickly and effectively as possible.    For anyone who is paying attention, Agile is really just Waterfall on a compressed time schedule.  Think of Agile as lots of Baby Waterfalls.  We’re still gathering user needs, translating them into specifications, coding, then testing against the specs, but we’re doing it in two to four week time boxes instead of three to six month ones.

With no points for craftmanship or burndown rates on quality, software has become life in the fast lane.  Everything, all the time.  With daily check-ins, a culture of “sprints”, and a clear agenda of speed over quality, let’s be careful that Agile doesn’t become just another fast-food corporate construct to build garbageware and make good developers work like dogs.  People have burndown rates, too.

Share/Bookmark

Is your shop heading in the direction of continuous integration and automated unit testing on an enterprise scale with code you plan to keep for 3-5+ years? Then invest the time to head over to MVC 3, understanding that it may add 10-30% of effort to ongoing development.   Still hand-testing those modules and releasing from developer machines with code that’s already obsolete? Save yourself some time and use regular ole ASP.NET.

Don’t get all MVCed up with no place to go.

Share/Bookmark

Dan has been asked to speak by New York City-based organization, Leaders in Software and Art (LISA).   He will speak on the use of software and video technology in the arts.  He was chosen by Erik Sanner for the originality of his portfolio of works and his use of video technology in production.

His work is of interest to LISA as it resides at the intersection of art and technology. Other LISA speakers have included noteworthy artists such as Scott Draves and Anne Spalter. The event is on Dec. 18th, 2011 by invitation only.

Share/Bookmark

Pragmatic Programmers’ Ship It! by Jared Richardson and William Gwaltney(2006) still hasn’t gone out of style. It lays an IT Shop 101, 202 foundation that’s extensible by the modern flavors of Agile, Scrum, etc.    The upshot:

The Code

• Developers should use a Sandbox and check code into a Repository.
• The Repository should be managed by a Source Code Management tool.(e.g. Perforce, Subversion, MS TFS)
• Features and Bugs should be tracked by an Issue Tracking system.(e.g. Bugzilla, TFS, JIRA)
• Code should be checked in and builds done daily. (Continuous Integration)
• Build should be scripted to run on a Build Machine, runnable by any developer with a Single Line Call.
• Test Scripts should be run automatically at each build, testing issues fixed by recent code changes.

The Team

• The team works on tasks from The List, a single list of all high priority bugs and features.
• The Tech Lead acts as project manager, product manager, and coder, handling bug and features requests, prioritizing them, and assisting team with their execution.
• Daily Meetings to check in on status.  Keep the individual updates short. (1-2 minutes)
• Frequent Code Reviews.  Keep them short, relatively casual, and fluid in regards to who and what.   “Regular code reviews don’t just make better code, they make better developers.”(paraphrase)
• Set up Source Code Management system to send emails to all team members containing the contents of each build.  i.e. Release Notes for each build

More to Come…

Ship It! A Practical Guide to Successful Software Projects, Jared Richardson, William Gwaltney, Pragmatic Programmers, 2006

image courtesy of Evan Walsh

Share/Bookmark

Circles and Rounds, Dennis Miller

The dramatic glass-enclosed Waterfront Square Atrium at Atlantic Wharf is the site of an exhibition of slow-moving dynamic digital painting, digital animation, and algorithmically generated software that explores fluid dynamics and digital and artificial life. Works included by Brian Knep, Andrew Neumann, Robert Arnold, Dennis Miller and Dan Hermes.  Details here

Share/Bookmark

Doesn’t innovation require inspiration?  Allow me to inspire you.  As you may know I’m a keyboardist and composer of note.  I’ve released a piano album that will let you decide for yourself if I should be allowed near a recording studio.   Visit, listen, and steal some free tracks at www.hermesorchestra.com.

Share/Bookmark

A HealthcareSource spinoff startup, Healthcaresource.com, enlisted me to help build a new product for them called Sourcing Manager.  It’s now done and successfully brought to market.  Users are clamoring for demos and signing on to for year-long license contracts.  The value this product provides is so significant that users can recoup the costs of the product in a matter of weeks.  Not bad, HealthcareSource.

Congratulations Troy Hatlevig and team!  Special thanks to Susane, Sindhura, Todd, Heather, and Les.

Share/Bookmark

Most people work in the IT industry because it can be a reliable way to make a living.  Making a living requires a paycheck.  This paycheck is the difference between hackers coding on their own time and professionals in the software industry.  Where does this money come from that ends up in your bank account?  The customers, of course.   You’ve  probably heard a million times about the importance of the customer.  That’s because it is true.  This is particularly difficult for techies to swallow sometimes because most of us get into this business because we love the code.  We’re not interested in business or sales.  This accounts for the cultural rift between the business side of a company and the technical side.  Ask yourself, how often do you see the salespeople chumming around with the geeks?  No, not often.  The reality is that it was very likely a meeting of a salesperson and a geek, somewhere, at some point, that made your company possible and/or continuously successful in the first place.  It is the salesperson’s job to locate customers and keep the business aligned to serve them so they are comfortable purchasing from your company.  Everything we do in this game of softwareball serves no other purpose than this.    No customers, no revenue. No revenue, no IT shop.  No IT Shop, well, you get the idea…

So what is the ball in Softwareball?  What do we need to keep our eye on the most?

The Customer.

Here is where is gets complicated.  In an IT Shop, there are many ways in which we keep our eye on the customer.  We do it first and foremost by aligning the shop with the customer needs.  In software procurement, product management, analysis, and gathering customer requirements, we set the U.S.S.  IT Shop on the bearing of serving the customer.  This alignment happens within certain parameters, certain restrictions decided by the management in your company:  Budget, schedule, and scope define the playing field for each game.  Business and technical managers wrangle back and forth to define this field.

Analysts and testers serve the customer by remaining focused on the all important question: “How can we ensure that the software meets the customer’s needs?”.

Project managers ask “How can we serve our customers without running out of time or money?”

Developers and designers ask “How can we build this product so that it serves the customer reliably today and allows me and others to work efficiently on this project in the future?”

Architects ask “How can we design the foundation so we may build products on top of it to serve the customer effectively, allows for reliable product growth, and creates a natural, efficient workflow for the developers?”

As these different folks go off to do their jobs, the word “customer” may actually be used infrequently in their  daily routine.  We are building software, after all, we are not salespeople or therapists.  What happens in an effective shop is that the idea of “customer service” is ingrained and innate in even the most technical and esoteric tasks.

Effective IT shops never lose sight of the ball, their customer.

Share/Bookmark

The reasons can be many, and require a full analysis of the shop to determine the cause. Look first at the project plan. Is there one? Does it take all phases of development into account: analysis, QA, installation? Is there a clear process of requirements gathering or are new features developed as they arise? Is the project too large for the team? Do details seem to get lost due to tracking problems? Is the product delivered only to find that more requirements arise or new defects are found?

Break down the process of product delivery into these stages: planning, requirements gathering, development, testing, and installation. Look at each stage closely and find the hang-ups. Talk about the weak points candidly with your team. It’s likely that someone on the team already has a solution and has been waiting to be asked.

What do you think about this?

Share/Bookmark

Animation – Silverlight
File size – Flash
Scripting – Silverlight
Video/Audio – Silverlight
Sound processing – Flash
Accessibility – Flash
Platform compatibility – Flash
Text representation/SEO – Silverlight
Supported image formats – Flash
Socket programming – Flash
Webcam support – Flash
Deployment – Flash
Windows application – Flash
Media streaming – Silverlight

Other Adobe vs. Microsoft face-offs:

Silverlight vs. Flex C# is a real OO language vs. ActionScript which is not. Flex looks better.
Illustrator vs. Expression Design Expression Design is not a head-to-head competitor with Illustrator as a standalone graphics editor, just a handy XAML-friendly tool to use with Expression Blend.

Coming Soon:
Dreamweaver vs. Expression Web
Bridge vs. Expression Media
Adobe Media Encoder vs. Expression Encoder

Share/Bookmark