02 February, 2013

Graduating from Programmer to Engineer: Benefit of doing total life cycle development.


A thread in the java forum on Facebook posed the following question:

"What do you think: is it better to learn
1. HTML and CSS
2. JavaScript
3. Database design
4. SQL
5. Java  "


First off, this question really applies to those that have the aspiration of doing what is called total life cycle development, people who wish to be generalists of the entire software development stack for an application. To touch all aspects from class design to UI development. This is always good experience to have but often developers are segmented into each tier as each can be it's own world of complexities and issues, languages and best practices. However, doing a project end to end can provide a great deal of the talent that comes with experience that turns a programmer of code into an engineer of systems. I have full belief that ones options for growth as an engineer and in the field are far greater once engineering skills are gained beyond the sandboxed mind set of "programmers". I have spoken on the difference at length in an other post.

I can say having embarked on a large project over the last 11 years that originally started with my novice understanding of the java programming language that it was far more instructive to start with the core elements of the business logic and that required that I fully understand the OO features that java could provide to significantly collapse the difficulty of coding a scalable, extensible, db agnostic, web based platform BEFORE any such platforms existed in the wild.

The bulk of the code that I wrote for persistence, scalability, security and workflow was purely de novo as there were no third party solutions to plug in and use at the time (2001). This was a great situation as it forced me to create what I needed without pollution from the ideas of other implementations which could have detracted from my ability to design the optimal class hierarchy. The drawback of course was that design time for each component would be required but that meant I could get the practice with obscure aspects of the language that would cement engineering (as well as) programming mastery. (There is a big difference!)

So, I needed to learn about the details of the reflection API, I needed to fully understand RTTI and had to realize the power of run time extensability and writing a custom class loader. I had to fully understand how to use threads, control their populations, segment their access to memory, disk and data resources without creating pathologies (deadlocks,race)....I needed to fully understand how these pathologies could emerge very differently under scaled and loaded conditions. Understand the impact of the network on the architecture, the impact of load on the union of the two, address geographic load and scalability. In short all the big giant problems of enterprise software development came into play over the course of the development.

I spent almost 2 years coding core classes before I even got to client code implementations in user interfaces. The db schema was designed in parallel with the object structure and served to cement my skill with SQL and the need to support a variety of DB vendors enabled me to explore creation of a persistence API that was agnostic to vendor DB's. All of these experiences were of huge value as they allowed me to encounter the sticky problems that are often in the purview of those that have been in the field. You don't get these problems in cs 402 on advanced data structures...even if in some ways data structures are involved in solving those problems...they are in a distal way...these is what I mean by engineering versus programming.


In summary, greater value I think can be found by starting with the core language, that ties almost invariably to understanding the data model (db) and then later when approaching the UI, the client coding issues present along with the issues revolving the templating technology (jsp/php..etc.) dynamic page scripts (javascript/ajax), services (json/xml) and design (html/css).

Links:

http://sent2null.blogspot.com/2012/12/functionality-stuffed-into-procedures.html

http://sent2null.blogspot.com/2008/04/another-bug-in-eternity-bin.html

http://sent2null.blogspot.com/2008/02/on-origins-of-comlexity-in-life.html

http://sent2null.blogspot.com/2008/02/objects-abstractions-symmetry-and-pop.html

1 comment:

Victor Karamalis said...

Prioritizing the business logic is the correct way to look at a problem. Coming from a public corporate environment, if you can sway your bosses (they hold the purse strings), it is approved. In Entrepreneurship, the same is true especially when asking for VC/Angel funding...