You kids get off my lawn! (oh, and the Apple iPad)

Lately I've been rather busy with work, primarily my main client as well as with the newer work I've been doing with a soon-to-be unveiled startup of which I'm a partner. Our product is launching by the end of the first quarter 2010 and I will be sure to update the site with all the details.

What is really on my mind lately is the annoyances I've been feeling more and more lately regarding what I feel is a loss of substance in the field of computing, interfaces and the sector of artificial intelligence research. Though just recently with the launch of the newly unveiled Apple iPad did I start to feel some alleviation. I will address several of the aforementioned items, but will leave the AI discussion for another post as it will be a lengthy one at best.

Firstly, as 2010 has rolled upon us I started reflecting on how it must be for kids these days and their constant exposure to computers. Primarily how difficult it must be for future programmers and software engineers to get started programming on machines so complex with operating systems so complex that to do even the simplest task requires learning what potentially are complex API's. When I was starting out with computers back in 1979-1980 one could buy a computer (which came with at least BASIC) as well as general instruction books explaining how to program in said language. Within 15-30 minutes any kid would be able to draw bitmapped graphics on screen and possibly even animate and/or add sound as well.

Given that the machine in question on which I first started (a 16-bit machine no less), the TI-994/a, was a 1.067mHz speed daemon, there is much to be said for its overall capabilities. This blog post is larger in size than that machine had RAM (a whole 16k's worth). So, it is true that with all of the amazing capabilities and speed of our newer machines (such as my primary machine with its 8 hyperthreaded cores over two physical quad-core Nehalem Xeon's and 6gb of RAM (of a possible 64gb)) it would be expected. Still, something is lost in the overall simplicity.

Furthermore, my recent curmudgeonly slanted mindset spread to thoughts about how access for all destroyed the quality of the average computer user, especially those networked users (which nowadays includes virtually everyone). When I first started online, there was no AOL, there was no web, there was the internet, but it was limited to Academia, Science Research facilities and the Government. We had modems primarily running at 110/300/440 and later 1200 baud and up. We had acoustic coupler RS232 interfaces (they while novel, are not something which I find myself longing for once again) and we were happy as can be. We knew that getting online and/or running into other computer programmers/enthusiasts (they were usually one in the same back in the day) would lead to interesting conversations/exchanges of a higher intellectual level as opposed to nowadays where the overwhelming majority of computer users are simply that, users who couldn't code their way out of a cardboard box.

Enter the Apple iPad. A machine designed for everyone BUT programmers/software engineers & developers. It provides the mundanes with the functionality to go on about their daily online existences and I'm truly hoping that such devices as this catch on. I hope that items such as this replace the majority of those users' computers. This would give us a kind of return back to the day when the technorati and intellectually gifted were the only ones with machines capable of creating new software. It will help like minded people easily be able to pick out those of similar ilk simply by their possessing an actual computer.

Now I realise that there are people complaining about the iPad specifically those under the spell of Stallman (RMS) and his free software foundation but it is time for them to be grown ups about the situation. If someone creates software, it is their right to keep the source closed, just as it is Stallman's right not to run it on his machine(s). He can be an idealist with cramming such a non-sensical mindset on everyone. Most people really could care less because there are those sources which provide for the applications people want and use, and have no desire (or capability) to modify them anyway, hence the iPad and future devices of similar type are perfect as end users are consumers of the fruits borne of software engineers, not producers of such software.

Now I realise that as usual, I'm diverging from my original topic by going off on a mildly related tangent, so i'll wrap this up by simply stating that it is my hope that with the newer type of device designed solely for the everyday user that we will see a reduction in actual programmable computer sales indicative of a clear divide between producers and consumers once again making a clear distinction between those with the mental prowess and logic abilities/desire to create software and utilise machines to their fullest, and those who are simply consumers of said labour.

Thoughts?

Enforcing the Software Engineer Archetype & Related Principles

It is hard to believe I've been engineering software for the past 14 years, mainly because that isn't reality. I started off like most others, as a programmer/developer and grew personally and professionally over time. As time progresses in our studies and experiences in design, development and deployment we change. This change is more oft than not, for the best.

When I was growing up, I looked towards getting a CS degree so as to become the aptly named "Computer Scientist". What I've found over the years via practical and situational based circumstances is that Computer Science isn't my primary interest. While it is true that there are pieces of the CS realm which have always garnered my attention, such as Artificial Intelligence, it doesn't ring true as a whole.

Today reminded me just how much I would like to think I have changed both in my focus, overall goals and discipline pertaining to the whole process of building software systems. Now the example I'm going to loosely reference is centered around phase one of a much larger long term project. This first phase was somewhat of a rush job as per the client due to botched (i.e. prematurely advertised) promotions for said application's 'live-date'.

I knew that taking this on such short notice would require a very strict set of time guidelines and clearly defined checkpoints and milestones if all was going to be implemented in a proper manner, one supporting a proper holistic software lifecycle approach. This of course required the initial overview of the phase being clarified, the requirements gathering phase, the initial layout with timeline estimates and expectations being put forth and finally said estimates being agreed upon with a little 'wiggle' room so as to allow for human error in the previous steps.

Well, here's what happened today which precipitated this posting. This project has a launch date of 15-Jun-09 and today being the last business day prior to that date, one could say that the end was almost upon me/us at the time. Weekends are out because as an adult and a family person with children, I value my personal and family time very highly, much higher than that of my professional work. That being said, I am indeed an experience professional and know how to accurately plan work into a give time frame clearly stating what can and cannot be realistically expected within a given time schema.

Today approximately one hour before the weekend officially arrived thus signaling the end of this phase of the project, both the designer and the overall project coordinator (not on the Software Engineer side mind you) started throwing out 'new' items for this existing phase almost completed. It is at moments such as these where the undisciplined and junior level individuals panic and ultimately sacrifice their own time for the sake of someone else's lack of professionalism by agreeing to make the changes.

I did the opposite. I made the correct move by stated clearly to all parties that we had agreed upon timelines and that they have been kept. The idea of introducing new components not part of the original design at such a late stage of the phase was outright idiocy. I pride myself in my completeness of the whole process and will not let a failure to plan on someone else's behalf negatively affect the quality work I strive so hard to ensure. Any changes need to be reviewed to ascertain what side-effects might be caused by their inclusion (especially into a more mature codebase at this point) and not to mention the quality/testing cycle which obviously wouldn't be possible due to time constraints.

What I am trying to get at is that I learned that for the sake of professionalism, quality and ethics, one must have the ability to say "No" when others fail in their planning/design. After all, the requirements gathering phase is when a competent Software Engineer brings to light questions that would hopefully coax such ideas from the requirements 'givers' if you will. It is our duty and creed to help our clients both internal and external to bring clarity to their actual needs as many times they are unsure of the specifics until discussed with others.

So I say unto aspiring Software Engineers of the future: People look to us for accountability, and part of that equation is keeping the other variables in the equation (team members, requirement providers, planners, designers and what not) accountable to the process, even if it means telling someone 'No'. Provide your reasons, and hold steadfast as these software engineering processes exist for the benefit of our projects' quality and overall success, not for the sake of being friendly or 'helping out' someone who failed to do their part in the overall planning and execution of a project and/phase thereof.

Django Projects Galore and Vile Ethics of other Coding Firms..

It has happened yet again. I've been brought on for another Django project. This time it is about taking an existing site for yet another magazine publisher and converting their Wordpress driven site into a real full-blown site complete with blogs, forums, user profiles, dynamic main page content, complete customisation from within the framework and included applications and ultimately a site in which a developer is not needed for day to day changes.

As it exists, this publication is an off shoot of their primary magazine. A magazine whose website was written and managed by an outside from that I believe coded the entire site so as to require additional invoicing and servicing for all but the most minute changes. This is a disgusting business model and one with which I've had the misfortune of experiencing whilst working as a sub-contractor to a sub-contractor for Burlington Coat Factory.

The H-1B Visa Project Manager who wasn't too fond of me because I don't believe that coding in dress attire and/or a tie makes someone a better worker (to the contrary, i will NOT wear dress attire for day to day work as it is a pointless expression of old brick-and-mortar mindsets). He also was the first time that I was reprimanded for having an eloquent solution that adapted automatically to the growth needs of the end-clients database/system. I wrote the software to handle dynamically gathering and sequencing additional 'like' fields as they were added to Burlington's transaction schema. The way I designed and wrote the software, the MOMENT the schema changed, my software contributions would immediately include relevant changes, without a restart of any of the daemons I engineered. I was told that the reason why i shouldn't have done this is because the sub-contractor for which i was writing this code could then go back and charge an exorbitant amount of money each time minor changes were made. This disgusts me, and I find it ethically wrong.

I am an engineer and work independently by choice as I can first and foremost hold myself and solutions I produce, to higher standards; delivering what my clients want and need, not solely based upon what they say they want and most definitely not building them into a corner for profit over common decency and professional standards.

Once the project has been completed, I will be quite happy to share the url(s) with CodeDEVL readers.

In defence of the lone coder archetype

All too often these days we see companies and methodology evangelists touting the system du jour whether it be Extreme Programming (XP/Pair Programming), or Agile as being the "One True Path" to coding enlightenment. All other be damned is roughly what said mantra translates to in common speak. We're told to beware the engineer who works alone in a dark back room for weeks on end. We're told to such a thing is heresy against the gods of modern application development.

We're being lied to by the methodology evangelists. I'm not here to down speak any of the other methodologies currently in use for software development. I am here, however to point out the benefits of the 'lone engineer' (not to be confused with the lone gunman). Lets set a few things straight though.

A coder with little to no professional experience in the field is not the optimal individual for this kind of setup. This is more for a seasoned professional who has at least been a team lead on several projects from conception through maintenance phases. I'm not saying it isn't possible to pull it off without significant experience, but I wouldn't place bets on such an individual succeeding at the whole task at hand in said company.

This kind of environment requires a disciplined engineer. We're talking about someone who knows the questions to ask, and how to dig deep to find the true needs of the client(s). This also means that the engineer needs to stand his/her ground when it comes to setting a solid schedule for phases of the project(s). There is room for variability in terms of time frames for each phase, but that the plan must be laid out in a linear fashion. This is engineering after all, and one doesn't plan to build the rooms before the foundation is laid.

Agile methodologies are more akin (though not parallel to) modular housing construction. Individual sections or units can be build simultaneous and changed (to a certain extent) by separate sub-teams. Whereas the lone engineer mentality is more akin to traditional construction in which the design is finalised, the foundation is laid and construction occurs in layers from the bottom up with customisations being generally last.

This isn't to imply that software built in this manner cannot change or adapt in a timely manner, far from it. Seasoned engineers/developers understand that the only true constant is change. We constantly work on new ways in which to design flexibility and mutability into our systems regardless of the specifics. This however just goes back to one of my earlier points in that this requires someone who isn't wet behind their ears. You can only know and plan for the unexpected via flexible designs after having cut your teeth in real world projects, and by faltering. Everyone makes mistakes, and it is through these mistakes that we grow and better ourselves. I'm not implying that senior level engineers don't make mistakes, I'm just pointing out that their success to failure ratio is pretty strong in favour of the success side.

One of the key benefits of the lone engineer methodology is that focus can remain solid with no deviation due to intra-coder/intra-team conflicts. And while this can at teams be a negative, overall it proves itself beneficial towards the ultimate goal, a finished software package/eco-system designed from the ground up to benefit the requisitioner(s)/client(s).

The issues of coding standards still must be kept, however there is definite consistency when only one individual is involved. This is also a liability as said engineer must have strict standards, commentary and documentation from beginning to end so that in case of any situation rending the engineer on the project incapacitated in any form, another could come in and continue with minimal delay. These are issues which affect other methodologies, some more than others.

There are downsides as well though. There are no direct peers upon which one can depend in times of need or collaboration. There are no peers to assist in code review sessions, meaning that the QA of any project must be proficient at testing, and enforce strict recursion testing when any changes are made to a product in production as QA becomes that final line of defence against human error. The reality is, no usable (as in serves a real purpose) piece of software is bug free and to think otherwise is the sign of a fool. What is realistic is having a system robust to handle errors when they occur, even if that is infinitesimally infrequent.

I'm getting off track here. My point is that in this newer, more extreme era in which coding fundamentalists believe they possess the one-true-way of coding and all others be damned, we must step back and realise the grave miscalculation they are making so boldly. After all, those methodologies weren't what were utilised to get us where we are today, nor were they even thought of when some of the staples of our art were invented. This doesn't mean that the next great piece of software or language won't be produced in such a manner, as it/they may. It means that we as professionals shouldn't be so narrow minded with tunnel vision when approaching different methodologies in an attempt to find which works best for the project/company/industry at hand.

Simulae3: A Testament to Socratic Design.

Socratic Method: the pedagogical technique of asking leading questions to stimulate rational thinking and illuminate ideas.

When I first started working on SimulaE (long before it was even referred to by the aforementioned name), it was a solo project.  This isn't to say that I haven't written all of the code from day one to this very moment, because I have.  I can however say that the design portion of its various incarnations wouldn't have evolved in the manner which they did were it not for the diligent use of the Socratic Method.  

My earliest versions of designing the Simulae virtual world simulation suite of libraries and what not were designed and written by me in response to the original interactive fiction/text adventure engines, then consequentially MUDs (Multi User Dungeons).   The proof of concept of building a better designed mousetrap was simple enough to bring to fruition.  This took place over years, dependent upon my free time and interest in furthering what was simply a flight of fancy for me from my programming youth and Zork playing escapades. 

What really became apparent was when I worked for another company and had the pleasure to work with a very intelligent individual by the name of Tim.  He is a systems/network administrator as well as a capable coder though the latter is not his primary goal, nor role professionally.  

Tim was interested in my Simulae project and as such I found a kindred spirit through whom I could interact by applying the aforementioned Socratic Method.  Through a constant back and forth barrage of theories and examples along with postulates about the hows and why virtual components modeled after reality need to be viewed in a certain light, we would come up with a whole new understanding about the direction of the project.  

It was during this time initially working together that the present tense English Parser component (parser.py) came to be realised and produced.  It took a total of seven point-releases to go from simple noun verb understanding to parsing complex compound sentences with a massive understanding of 45,000 adjectives, 9,500 verbs and multitudes on various parts of English speech.  This series of productive success if anything re-enforced the validity of this methodology in the realm of software design. 

It is now though, with this in mind that I have taken utilising this method to the next level and enacting it with completely uninvolved individuals (uninvolved in the sense of the projects topic and internals).  In the past several days Simulae3 has emerged from the bowels of my TextMate application.  The code is simple, shorter and far more capable than any previous incarnation and things are moving forward at a great clip.  

This brings me to the current point of interest and a call for assistance for anyone willing to get into sometimes heated dialogue about object models.  The object model system is based around the three basic SimulaeObject types.  The only piece of the puzzle still causing an issue is the matter of Portal Objects (entranceways between other container type objects.)  

For the sake of argument, just look at it this way:  A room is a container, that leads from one room to other rooms of 'greater' building enclosure.  A set of lips in a Mobile Object (hereafter MOB) (e.g. 'actor' in OO/UML terminology) is simply a Portal Object to the mouth of said MOB.  A window is simply a portal between the outside 'container' object (in this case a root SimulaeObject), and the room in which our Actor/MOB would be in (to see said POB destination from said perspective).  

I need others with whom I would be able to work out ideas so that this conundrum can be resolved and the next phase of Simulae can come about for code release and testing.  If anyone is interested, contact me at this domain via my email address: eric

I am going to finish on that note being that due to medical reasons dealing with my sciatica, I ingested a full dosage of two Vicodin tablets (as per my primary physician), and as such I'm getting ready to crash hard.   I hope to hear from some of you in the hopes of moving forward, but I'd like for Tim to give me a call in any case so that I we can bounce some ideas back and forth on these issues.

Reflections on 2007, Looking forward to 2008

Given that it is nary a few minutes past 22:00 on the east coast of North America, I figure it is time for one of 'those' looking back and looking forward type posts, but with a codedevl slant. This past year has been a rather bizarre one as it marks the first year of my professional career (over 13 years) in which I've been employed by more than two firms/companies. I mean technically I've only been employed by one firm, the time prior and currently I've been self-employed, so does it count?

While this isn't necessarily an issue for many others out there, it was a point of concern for me as I have been traditionally conservative in my career moves and choices. It isn't as if I'd suddenly threw caution to the wind and job hopped. I will say that it was all thanks to the federal government for starting the ball rolling over a year ago when they raided the offices of a previous employer due to nefarious actions of several of their customers (unbeknownst to any of us at the time). The government claims it wasn't a raid but a search and seizure. As far as I know, that is classified as a raid, more so because the agents were wearing bullet proof vests with guns drawn.. all three dozen of them.

I've started to obvious stray from the where I was going. Simply put I found myself working with a skeleton crew at a company for an additional five months while legally being unable to process our normal transactions, hence no hope of future work. The warnings started coming and as such, the few of us which remained knew the end was near so we all started prepping for the day when it would all come crashing to an end, an end to a wonderful half decade as a working family as it were. It took less than a week for me to land a new gig working on a project for Burlington Coat Factory and previously mentioned in a previous entry. I do have to say that I grew more as a software engineer during that first jump into contracting than I had in many of the prior years, including my time as team lead, department lead and CTO.

I brought all of this us because it lead to how I started out the year of 2007. I was finishing up my contract having successfully deployed the new point of sale returned goods system for Burlington's stores nationally. I knew when my last day would be and started to look for interesting jobs, but preferably salaried ones, which I found without trouble, so much to the point that I finished my contract on a Friday and started my next job with Blue Gravity Communications, Inc. the following Monday. As that saga has also come and gone (by my own choice), many things have changed, primarily my outlook on contracting vs. salaried employment, my work environment and my work ethic.

I found that there really isn't a major difference between salaried employment and contract employment, other than the 'false sense' of security in a salaried job. The reality of it is that one can be let-go from a salaried position very easliy, unless you're in Nederland, France, Denmark, Sweden or Norway (and a few others I'm sure I forgot). The overall benefits of being self-employed become clear rather quickly once the newness of contracting fades away. You have more responsibility, and more freedom.

You work harder to prove and build and/or strengthen your reputation, and don't mind it. You have flexible hours (at least in my case and/or other cases where on-site 9-5 is not required, which is a pretty common flexibility. You don't have to deal with as many managers or supervisors. You don't have to stress over working with a certain group of people forever. You are able to work multiple clients simultaneously (as much as you can personally handle), and finally, you truly have more control over yourself and your future than ever afforded in a salaried position.

My environment was always a sticking point throughout my various locales of employment, ranging from a room full of others in a different department, a room full of peers, a room full of subordinates (though I hate the term, being very much an egalitarian), and of course, in a room all by my lonesome. I worked many of my years in a solitary environment, for a full time employer and as such had plenty of human interaction. Yet during those years I yearned for more interaction, a room in which I could openly be around others. I finally got my chance when I became CTO and Development Lead at one company. I was able to secure an open office with no partitions and a relaxed layout.

This proved to be an enjoyable environment, but I found later on that it didn't allow me to produce my best work. Separating myself from the others didn't do much to help either. It was only when I worked as a contractor for my first time that I started to realise what my environmental needs are. I returned into the salaried world and worked side by side with some great people, even entering into the halls of foosball with one of my aforementioned peers. It was only after I re-entered the realm of self-employment contracting for Pinchazo Publishing Group, Inc. (owners of Nylon and Inked magazines most notably), that I setup my home office an came to terms with a new reality.

I work best, in my home office, alone with minimal contact from others with the exception being my request to speak with others over designs or processes changes in order to meet project/structural demands. I do enjoy the company of others but know that I work more diligently, more exacting and am ultimately more focused when in my own space. I did find however that this new environment does have its perks, one of those being flexible time to meet up with peers and past co-workers for quality time.

This leads me to my final point of realisation. My work ethic has changed dramatically for the best. To be honest I found that I was too easily distracted in other environments when a salaried employee. I had far less "in-the-zone" moments when in a workplace, and on someone else's payroll. Again I think this is due to distraction and a certain level of security (a false one at that). I'm not particularly fond of making this public admission, but at least I've recognised it and willingly state it for the record. I know what I need to be the best that I can, producing the best work of which I'm capable. Now that my reputation and future prospects rely mostly upon my current projects and the manner in which they are complete, it makes me stay more focused and on task.

I also must say that due to the lowered stress in my career at this juncture in time, I am able to enjoy my art/trade for more than ever before. When one couples that feeling of relief along with my combined experiences, gained knowledge and wisdom (or lack thereof at times), caring becomes a top priority. I care about my work, and I strive to produce the best that I can. I own the process, the engineering, the schedule and the maintenance and as such demand of myself nothing but my best, and I love every moment of it now. I know what I'm worth now, and I know what my code and expertise are worth and what it takes to ensure that I'm operating at my best.

Finally, this brings me onto my outlook for the upcoming year. Hopefully, much of the same and barring any catastrophes, I see a very promising future ahead with the current outfit for which I'm contracting. The work is exciting, doing things the right way and engineering a whole system is something upon which I thrive. I look forward to learning new technologies, I'm excited about the prospect of new advances and of course, I'm happy that I love coding and truly feel as if I've found my ultimate environment to do what I feel that I do best: Engineer great software.

Happy New Year to all, here's looking forward to a great 2008!

Eric