My foray into web application development is proving to be a worthwhile learning experience. At the outset, six months seemed to be sufficient for creating an alpha version of the application. As might be expected, it has taken longer. However, I am not bemoaning the usual software development road bumps–far from it. A month or so in, I realized that while creating a web application would be great, that goal should not overshadow the benefit of learning as many professional development skills as possible. As a result, the focus has been on honing my dev chops as much as it has on product development. Here are a few things I have learned along the way.
I’ll See Your Object and Raise You a Framework
Once I decided to go with PHP over C# (there is simply too much open source PHP code for every possible application type to ignore), I thought it would be relatively easy to jump from procedural PHP to an object-oriented MVC PHP framework. Nope! It is one thing to build one’s own simple MVC framework and quite another to use (and understand) someone else’s object-oriented (OO) version. Since learning the deeper aspects of software architecture and design is a key objective for me, I decided to write a limited procedural version of the application, then do a home-grown MVC version, and finally move on to an OO framework. Through each iteration of the application, the focus has been on understanding how specific design/architectural choices affect extensibility, scalability and performance. The product is behind schedule by six to eight weeks, but happily, design patterns are less mysterious; interfaces are obviously a good idea; and dependency injection is beginning to make sense.
Knowing an object-oriented language (i.e., familiarity with classes, inheritance, encapsulation, and polymorphism) is only a part of knowing how to build object-oriented applications. It is easy to slip into writing procedural code sprinkled with classes. Object-oriented analysis and design take time to learn and are best tackled once one is comfortable with an OOP language. Further, understanding why a particular design is superior to another often (at least for me) requires running into a design problem and wrestling with it until a light goes on. Thankfully, the rate of light-bulb firings is increasing.
While learning new things, especially programming related things, is flat out fun, my desire to understand frameworks and development environments has a business purpose as well. One of the major issues facing any technology firm is finding capable developers. When the time comes to hire developers, I need to be able to determine who is good, and the only reliable way to do that is by understanding what they do and say. Ergo, my learning is for business as well as for pleasure.
UML modeling works great for expressing user requirements via use cases and for creating data models with class diagrams. However, aside from these applications, I am a Petri net convert. Modeling processes and interactions with Petri nets is not only less cumbersome, but also more expressive than with comparative UML diagrams.
To Market, to Market…
The economics of software development has changed in remarkable ways, at least from my perspective. Thanks to the open source movement, the tools required to do professional-level software development are readily available and free or inexpensive. Cloud-based as well as regular hosting packages are making it inexpensive to launch a site. Back in the ‘80s, I created a utility program that sold for about $30.00. Generating sales was difficult because it required advertising in a magazine (expensive) or getting the product into a retail store (impossible). Now Google, LinkedIn, Facebook, blogs and the like, along with app stores, make it far easier and cheaper to find potential customers.
Not your Father’s Development Tools!
Pass the Data, Please
Putting Your Best Face Forward
As the alpha version of the web application draws closer, I have spent more time thinking about the specifics of the user interface. This probably seems to be a little late in the game to think about the user interface, but actually, it isn’t. The number of features available in version 1.0 has been intentionally limited so that only a few screens are required to access them. Therefore, until recently the focus has been on under-the-hood stuff. Now that the application’s core is solid (fingers crossed), it is time to refine the interface and determine the best screen layouts, colors, and interaction sequences. Tackling this challenge has led to my latest discovery: prototyping tools. While playing around with a few of them, it struck me that these tools, which allow one to experiment with user interface layouts and interactions, could be adapted to serve as usability testing and software selection helpers. I’ll explore this idea in the next post. Until then…