Agility is very important to me. In terms of computer science and managing application project management, from design to completion to maintenance, agility is one of the most valuable elements to large scale software design. I’m not sure if people know what it is exactly, but TDD, extreme programming, and the like all try to obtain maximum amounts of this sacred resource.

What is Agility?

Agility is the ability to move with speed, efficiency, and make mistakes and correct them in record time by knowing more about what failed. Imagine an application, or anything for that matter, where you can make a mistake and only be punished by 5 minutes of corrections. In that scenario, you can make any mistake you want and it’s not a game changer, difficult blocker, or any serious issue that slows down your team (*cough* adds to the critical path). That world is obviously impossible to obtain (at least currently) due to architectural decisions like language choices, frameworks, etc. but we can at least try to maximize agility after these choices have been established.

How do you maximize agility?

The key to maximizing agility depends on your project. In software, if you follow extreme programming you’ll get there. Here are some of the key points:

1. Sit together / Be there in person

   You need to be comfortable with your team; you need to succeed and fail together. We build things for people and the relationships on your team are important. It’s okay to have teams offsite etc. but as long as those teams also sit together and work together, they will benefit from this as well. Otherwise you spend far too much time travelling, typing, and misunderstanding people over IM rather than communicating instantly, receiving feedback instantly, and discussing things instantly. People need to get feedback instantly from someone else so they can build things the right way the first time.

    

2. Remove the friction — Say bye to cubes

   Cubes are the worst office invention ever. Examining the flow of information between a cubicle world and a non-cubicle world is virtually night and day. Overhearing conversations might be the BEST way to transfer knowledge and get those who know the answers or those who would like to learn the answers trained in a passive way. Cubes on the other hand are obtrusive to this kind of environment. As a rule of thumb, don’t put them in an office unless they really need to be on the phone consistently (sales/Bdev) or working on sensitive, confidential material.

    

3. TDD

   TDD is not absolutely necessary to having agility in the office but it is nice to have. TDD buys you confidence, knowledge, and potentially faster debugging times. In a perfect world, you would write the minimum test first, break the test, make the test pass, and do it over until the application is complete. This keeps you focused on the task at hand, causes you to write less code, and keeps you moving forward as you design and develop new features. Unfortunately, the real world isn’t so linear. You have to go back and forth as requirements change (agility), and you end up changing tests numerous times making you wonder if you should have wrote so many in the first place. At the end of the day, it’s a two edged sword. It causes you upfront time costs but I strongly believe it’s worthwhile in the end.

Share and Enjoy

So I felt like writing a new blog post rather than using tumblr or any of the billion other micro blogging or knowledge services out there. I still think there’s space for a blog, where blogs function as journals more than as primary communication devices. So I’ll start using it as that (and as tutorials like my other popular posts).

Computer Science Shift

Three months ago I moved from my agency-getting-things-done job to a start up working mainly with comp sci guys from some of the best schools in the world. This change has been full of new and interesting terms from clean code to hadoop. I’ve mainly worked on the client (Flash for our team) and a little bit on the server (PHP/MySQL/CI). Since joining, I’ve thought carefully about what it means to support millions of users and have boiled it down to a few select ways (which I can highlight in another post). Anyways, the change has been immense and I’ve studied very consistently since then. I’ve read a couple of code related books while keeping up with my regular readings. Most recently, I’ve finished a book on design patterns — yes the original GoF one. It’s come up throughout the last two years a number of times so I felt it was pretty important to read now that I’m in full blown comp-sci. Here’s a brief summary and opinion:

Design Patterns: You Shouldn’t Live Without ‘Em

If you are programming, or learning to program, and want to build scalable software, I urge you to read the original design patterns book (or something similar). Within the book, they talk about two dozen or so patterns that help organize common issues in software design. I found it immensely valuable to be able to talk about these design patterns with teammates and other professionals and why we choose certain ones over others. Here’s a list of the design patterns that interest me and what they do:

Creation Patterns 

• Builder – This pattern helps you create objects a certain way and then change them by using inheritance. You code out how you build a certain object in a class by using methods (build legs, build arms, etc.) and then extend that class and override those specific methods for various implementations. This is the same to me as using a similar pattern called template methods…
• Factory Method – A pattern that uses a method to create objects. I never embraced this enough until reading this. We use it in our code quite frequently and having something control the creation of your objects is powerful. Combining this with a singleton and other patterns allows you to determine at runtime which class should be used based on which class it’s being used by. Look up the term single dispatch as well (interesting concept), and if you can do double/multi dispatch with this, great.
• Prototype – An object you “clone” to create other objects with different behavior. Think events in flash; they have clone functions. Clone it, change properties, and send it out again is how I’d use them.
• Singleton – I heart singletons. Although they can be called “global” variables, they are safer to use than static classes and very necessary in almost every application. When there really should only be one instance, this is your friend. Unfortunately there’s so many ways of faking enforcement of a singleton in flash. I’ll be trying Casalib’s way for my next project. In full-blown OO where constructors can be private (like in Java and PHP), Singleton’s are even cooler.

Structural Patterns

• Adapter – The concept behind changing an interface of someone else’s library so that you can use your library to “plug” into it.
• Bridge – Separates implementation from abstraction. I loved the diagram in this book. If you have a multi-OS application, and need to separate how windows are treated, you can use a bridge to communicate between your windows and their implementations where the bridge is used to communicate to device specific implementations. I’d wager that most multi-platform dev kits use something similar.
• Composite – A base object that can contain other base objects. Think DisplayObject, NSView, whatever — every advanced visual language supports this concept. Parent -> children.
• Decorator – Adding functionality to something without having to change the original object. Their example was putting a border around a UI element. You can wrap an entire element to manage it as well and still be a decorator (managing many objects = mediator).
• Facade – I build “facades” to make using larger systems easier. It’s part of making coding intuitive. If something can be made simpler, it can very well be worth while to create a facade to interact with a whole system. I love using tool sets that accomplish certain tasks really well for example. And without having to build an Adapter, I can just create a facade that makes it easier to use it.
• Proxy – A proxy object is basically something that can 1) be used in place of something else, or 2) an object that communicates between two objects. I like that first point, that it can be used instead of something else. If something hasn’t loaded, you can use a proxy object to keep it’s place for fluid layouts or just to hold data until it’s loaded.

Behavioral Patterns

• Chain of Responsibility – Passing objects until someone interested does something with it. Think event dispatcher in flash. You pass objects from parent to child or child to parent while anyone along the chain has the option to stop it (stop/prevent propogation in JavaScript and AS3), handles it, or ignores it.
• Command – The command pattern is a very useful pattern to wrap requests to a server or servers (think p2p). By siphoning all logic directed outside an application through a pattern of objects, you have a very powerful, centralized hub to control communication (think control tower). This pattern is a must have for most applications.
• Interpreter – This pattern is very interesting in it that it allows you to create your own notation that gets parsed by an “Interpreter” that then opens windows, runs commands, etc.  Think regular expressions on steroids.
• Mediator – A mediator is a useful UI pattern that can be used to handle communication and states between multiple objects without violating encapsulation (i.e. those objects don’t know each other, only the mediator knows them all).
• Memento – Wicked name for a simple concept – a pattern that uses objects to store the state of an object so you can return to it later. Use mementos with commands to do undo and redo logic.
• Observer – A pattern that allows multiple objects (observers) to listen to a specific object for changes. Think binding in flex or the model to view or controllers in mvc, where the view or controller can act as observers. I loved CakePHP for this kind of observer behavior.
• Strategy – I love the strategy pattern. Consider you have an advanced algorithm and you don’t think it’s the best in all situations. You can wrap it in a strategy style pattern and build out another algorithm in another strategy and decide at run-time which strategy to use. It’s technical term would be separating an algorithm’s context from the algorithm itself so you can create different algorithms for a single context, vice versa, or many-to-many.
• Template Method – A template method is used when you write a base class with a certain sequence of methods being called in a certain order. The class is designed so that when you inherit from it, you can overwrite certain methods (called template methods) to present different functionality but keep the general structure in order. We use this all the time, everywhere (in good and bad ways).
• Visitor – Finally, I’ll talk about the visitor pattern. This pattern allows you centralize a certain behavior where you might want to create an object that scans other objects for certain parameters to do a certain thing or compute a certain result. The object is said to be called a visitor where it visits other objects to look for properties of interest.

You are probably using them already

Share and Enjoy

It’s been awhile since I’ve updated the blog’s look and feel. With WordPress, it’s super easy to do and frankly there’s no reason why I didn’t do it earlier. The new theme, which I will still need to modify slightly, is simpler, cleaner, easier to read, and a lot less busy with less noise and more focus on the text. More importantly, it is ready for mobile and looks beautiful on small and large screens. My objective with this new template is to help you get to the content you are interested in easily with less confusion and to look beautiful on mobile and desktop devices so you can read on the go, on the couch, or on the desktop.

Although lately I haven’t written on my blog, there are some posts I’ve been working on completing. I aim to have a new website out in a few weeks so hopefully around that time I will also post up some new useful content. I’d also like to take this opportunity to thank my current readers who have found many of my posts helpful and have shared there experiences through commenting and emailing me. I will work harder to improve this blog and provide valuable feedback and advice. Thank you.

Stay tuned.

Ayan

Share and Enjoy

I was working on a mobile app today that we were handed from another firm that lacked in a core usability component I consider very important: communication. Like one of my former employer says, communication is paramount. In the mobile space, it is even more important. Users’ hold onto the device and you can expect that they are looking at it. If you lose their focus, they might just close your app and do something else. That’s why it’s critical you let the user know what you are doing at all times. Whether it be hit states for buttons or feedback during potentially long loading times, communication from you (the programmer) to the user (your valued client) is critical.

Share and Enjoy