7 Habits of Highly Effective Software Developers

1. Design before Coding - We developers often tend to get straight to code spending little time on design. While too much formal and complete design is useless in building software systems, some basic design before coding is extremely helpful. Design does not imply writing a text document with pictures or UML models. Design can be skeletal code that is the basis for the full implementation. I try to first build data structures that hold system state and service interface contracts (not implementations) for the entire application as part of my design exercise. I then try to think through the application flow for various usage scenarios. Good design typically pays off in the end in terms of good quality code developed in a shorter period of time.
2. Re-factor continuously - This seems contradictory to the first habit of designing before coding. After all, if the design is good why should there be a need for re-factoring? The answer is - it is impossible to design software systems accurately and fully at the very beginning. Designs tend to evolve as the system is being built. Often times requirements keep changing. No one can get it right the first time unless you are building a very simple, trivial piece of software. Re-visiting previously written code and continuously re-factoring it is one of the keys to building good software.
3. Unit Test every quarter - No that's not company's fiscal or calendar quarter. It is the 1/4 milestone of your task completion. Break up your task into four, and after each quarter, think of how you can unit test the code you have written. Note that I'm not suggesting you should write a unit test, rather you should have a good mental idea of how one would go about effectively testing what's built so far. If what you have written so far is not unit-testable, re-factor the code to facilitate unit testing before moving on to implementing the next quarter of your task. At the end of a complete task, make sure a formal unit test gets written.
4. Write squeaky-clean code - All brilliant developers that I've seen write very clean code. Clean code means paying attention to removing dead code, avoiding compiler warnings, indentation, spacing, naming, and consistency in code style. This is more than just cosmetics - if your code is not clean, it is unreadable, unmaintainable, less likely to be reused and more likely to get re-written by someone else.
5. Comment code - The only documentation we developers will ever write is comments in the code. Keeping this up to date is of critical importance for the long life of the code. Any code where the logic may not be obvious to a new peer programmer should be documented. Documenting your code is not just for others but for yourself too - how many times have you gone back to your own code written a year ago and wondered what the heck the implementation logic was?
6. Be lazy - Yes, be lazy! Don't write your own code when there is good code already available for the same task. Don't re-invent the wheel. There are a ton of open-source utility libraries that are extensively used; make use of these wherever possible. Why waste time writing code when you can borrow someone else's code which may even be better that what you could write?
7. Get your code peer-reviewed - Peer reviews often help generate new ideas and perspectives on implementation that you may not have thought about. Set your ego aside and solicit peer reviews of your code.

Flex Uncertainty Doubt

If you are evaluating Flex and attempting to pitch it to your management, these are some issues that you are likely to encounter. As with any new technology, you encounter a mix of reality and FUD. This is my attempt at objective analysis of real and perceived issues with Flex that one typically hears.

1. Flex applications are too bulky - An empty Flex 3 application produces a swf file of roughly 150K size. Full-fledged applications can produce swf files of hundreds of kilo-bytes or even mega-bytes. This has historically been a problem. However, with current versions of Flex and the Flash Player, this can be mitigated in 2 ways - modules and framework RSL caching.
   
• A Flex application can be broken down into modules with each module being loaded only when needed e.g. on application startup, only the login module is loaded. This reduces the amount of bytes going across the wire each time, as the application is loaded in pieces depending on user interactions.
  
• Bulk of the size of a swf file is due to the Flex framework code. The Flex framework can be loaded once as a runtime shared library (RSL) across all applications and cached by newer versions of Flash Player 9 even across domains. So your application does not have to statically link in the Flex framework thereby reducing its size.
2. Why not just do everything with Flash Authoring (CS3?) - Flash Authoring is a designer tool while Flex is a developer tool. Flash Authoring is for producing creative, stylized content such as animations and graphics. Flex is the framework for application development. The typical usage is to build graphical assets in Flash Authoring, and bring them into Flex to incorporate into Flex components. Of course, if all you are doing is producing intro-screen Flash movies, stick to Flash Authoring. If you are building applications with re-usable components and business logic, use Flex.
   
3. Flex involves license fees to Adobe - The Flex SDK with its UI component library and command-line compilers is free. Flex Builder Eclipse IDE Plugin has to be licensed (no runtime license involved though). If your application uses server-side Flex Data Services (now called Live Cycle Data Services), that involves a significant runtime license to Adobe although a portion of it has been open sourced as Blaze Data Services.
4. Flex is proprietary - Yes, Flex is proprietary. But Adobe plans to open-source the Flex SDK - see this.
   
5. Flex applications are poor at rendering text/HTML - This is truly one of the big issues with Flex applications (actually this is a Flash Player issue rather than a Flex issue). Text layouts taken for granted in HTML are difficult to do with Flex. Flex has issues with system fonts and font embedding results in very large swfs. Adobe plans to provide better text support in Flash Player 10 - see this. Adobe's acquisition of Buzzword - the Flash-based word processor - shows its commitment to filling this gap.
   
6. Flex is not internationalization friendly - The lack of support for RTL (right-to-left) languages such as Arabic and Hebrew is a huge drawback. This is really a Flash Player issue and Player 10 is supposed to fix this - see this.
7. Flex applications are not skinnable - Flex supports applying CSS-based styling. However the drawback is that style sheets are compiled into swfs and cannot be changed without compilation at runtime by editing a .css text file (See this enhancement request).
   
8. Flex is architecturally inferior to Java Server Faces (JSF) - The comparison to JSF might not be an apples to apples comparison.
• JSF is a server-side framework while Flex is client-side. Flex can take advantage of the power of client-side processing that typical JSF applications cannot.
  
• JSF provides a formalized Model-View-Controller (MVC)-based framework with a component and event model for Web applications. While Flex provides an excellent component and event model, it does not have a full, formalized MVC framework out-of-the-box. One has to use frameworks such as Cairngorm if a rigorous, formalized MVC framework is required.
• In contrast to JSF Web-page type applications, building Flex applications are like building thick desktop applications (that happen to run in a Browser). Unlike JSF, in Flex one does not think in terms of pages rather in terms of application state. Therefore, the JSF notion of a controller that orchestrates page flow does not directly apply to Flex.
  
• JSF render kits for different UI channels is a great concept that works for output channels where there is server-generated markup such as HTML for browsers and WML for phones. Stretching this concept to server-side rendering of full-fledged thick client applications such as Swing, WPF or Flex is practically infeasible beyond a "Hello World" application.
9. Flex applications don't play well with the Browser back button and URL bookmarking - This is a valid concern. As noted earlier, Flex applications are like thick desktop applications where one does not think in terms of pages as in traditional Web applications. However, users are used to Browser Back/Forward functionality and bookmarking pages, and are likely to use it. Hitting the Back button with a Flex application may take the user to the page he was on before navigating to the page that loaded the swf. Bookmarking may not bookmark the state the user was in within the Flex application. The solutions to these issues include Flex's deep-linking and toolkits such as UrlKit. The solutions however require extra coding effort.
   
10. Flex applications are slow - Flex applications may be slow to load initially because of the size of the swf files (see 1. for ways to mitigate this). However, Flex applications allow for client-side processing that can provide superior interactivity on subsequent interactions by reducing server round trips. Using the optimized, binary AMF3 message format that Flash natively understands, one can achieve significant performance improvements over text-based formats. The new ActionScript Virtual Machine (AVM) in Flash Player 9 with JIT-compilation provides an efficient runtime for executing swf byte code. JavaScript in the Browser may some day come close to this performance, but it is not going to be happen anytime soon (see Tamarin).
11. ActionScript is yet another language to learn - ActionScript is very much like JavaScript (both based on ECMAScript). ActionScript 3.0 is based on Edition 4 of ECMAScript which is also the same base for JavaScript 2.0. which is not finalized yet. Adobe is ahead of the game with ActionScript 3.0 but it is likely that in the future ActionScript 3.0 == JavaScript 2.0.
12. With Flex I'm tied to the Flash Player and locked into Adobe - Yes you are tied to Adobe's Flash Player but the Flash Player is ubiquitous and free. As noted earlier, Flex is being open sourced. With the Flash Player, there is of course the issue of being dependent on Adobe for any enhancements you may need to the Player. For example customizing Flash right mouse-click context menus is not possible to the extent an application may desire (see this) and one has no choice but to depend on Adobe to fix it if and when it chooses to.
    

Flex is still relatively new and is likely to improve along with improvements to the Flash Player. But it is part of an emerging and significant change in the Web 2.0 RIA landscape. Flash-Flex/AIR and Silverlight/WPF are ushering in the next revolution in Web and Desktop applications which are easier to build and provide superior user experience. The days of DHTML AJAX applications and the struggle to provide rich user interfaces that work consistently across Browsers are numbered. The Web 2.5 (r)evolution is here.

M13

M13 Application Development Paradigms for large-scale enterprise applications:

1. All business functionality is thought of in terms of one or more services. An application includes a set of services and their implementers/providers.
2. A Service does not automatically imply Web Service.
3. A Service is defined by a Java interface and its implementers are Java classes. A Service can have multiple implementers.
   
4. Service definitions and implementers are independent of how the services are provisioned (Web Service, Java API, EJBs etc.), and are independent of the UI Channel (Browser DHTML, Browser Flash, Adobe AIR, MS WPF, Java Swing etc.).
5. Service provisioning is declarative meta-data driven.
   
6. Service implementers can be switched with configuration entry changes and without any code change. Services can optionally be versioned and it is possible to have multiple versions of a service active in the system at the same time.
   
7. For remote clients, a client-side service API is available for clients to code against.
   
8. Services produce and consume strongly typed objects and not XML. Optimized binary formats are preferred over text-based formats for data transfer across the wire
   
9. UI Components bind to strongly-typed, well-defined data models produced directly by the services without any intermediate transformations.
   
10. A common canonical form for clients across UI Channels is impractical and infeasible for any real-life application. Clients are written separately for each UI Channel in its own technology but they share the same services layer.
11. All application data can be broken up into 2 clear and distinct categories - meta-data and data.
12. Application structure and flow is meta-data driven.
13. All meta-data is efficiently query-able and stored in a relational data store. Meta-data is versionable and upgradable, and it is possible to have multiple versions of a meta-data element active in the system at the same time.