Blog

In reference to [Goldratt 1992]'s Theory of Constraints that suggest in every system there is a single constraint that determines the overall throughput of a that system. If developers are the constraint of your projects than your projects only move as quickly as your programmers can program them. In their book "The Art of Agile Development" James Shore and Shane Warden say that when the rest of the team outpaces the programmers, the work tends to pile up, falls out of date and needs reworking, and slows the programmers further.

While developers are generally overworked it is often mentioned that there is feasibly nothing that other departments can do to further help in the effort as development roles are far too technical ... or something. To them I would only recommend that it is not only commitment of the leader, but it should be expected of the entire team to spend their spare time eliminating the constraint by modifying the their function to better help support developers.

Traditional processes suggest that software should be managed as if ideas and innovations were being purchased off the shelf. Unfortunately the customer often pays for the time spent in the planning and conceptualizing stages that actually insures the road map to completion is as unyielding as the requirements permit them to be.

The problem here is that too much planning often incurs more requirements and more time identifying what those requirements are without any guaranteed forecast of what has to occur and without isolating any unforeseeable obstacles to get there. Nevertheless, with every failed project and every new project thereafter comes a brand new promise with a brand new process. While focusing on the internal antidote, an objective look on what has worked for all other players in the market is hardly ever considered. We are always positive that this time will be different while the new process is quickly prepackaged and delivered as their very own. Unfortunately, these solutions often introduce more problems later that corner the agency into straying from their own requirements because the process requires that projects are trapped within a time box that was negotiated before development ever began.

In this chapter I aim to point out that negotiating the ownership of source code is vital to both parties and we should always use a great deal of respect to our intentions before going into any sort of contract.  Also, we should never mistake our literal interpretations for our own misconceptions of what appears to be "legal jargon."  This sort of stuff is always best when both parties know exactly where the other party stands.

I must admit that this may have been a very ambitious topic to do in only one week after exploring the dynamics of such a problem.  As my research has been somewhat discouraging, I have found that their really is no line that is clearly defined though there is an entire library of perspectives on it.

Balancing life and work as a freelancer is really a skill in itself.  After leaving the agency life as a hired hand in hopes to steer my own boat, I really couldn't comprehend what it meant to be freelancer and the lesson I learned is that you must learn your lessons quick or die. However, I will admit my life as a freelancer has definitely been easier on the nerves, the time invested in my career has not let up one bit.  To be a freelancer you have to be a "Jack of all trades" and your really need to be a ninja at time management or you'll find yourself detouring all the time.   Also, if you don't know how to communicate effectively then that will probably be the biggest snag you will have to overcome immediately.  Being efficient is imperative for fathers, and mothers in this business and you have to know what your doing unless you have 80 plus hours a week and about a 100 miles of duck tape.

Anyway, as my experience as a freelance developer has begun to mature I am finding that I more and more of my time has become free again.  But as I am finally beginning to steer out of this work storm, I have been noticing about 10 more years of age pact into the last 4 years and I have decided that it's time to master true work-life balance.  I am beginning a category called "balance" where I'll keep all my stories to share.

Like many other web developers I reuse code. Reusing existing code assets can reduce cost significantly and accelerate the speed of development. As developers we hardly ever look at an application as an off the shelf product and often put a lot more love and overtime into the project assuming that it can expanded upon it while adding some more weight to our personal arsenal and save time later. Developers know that there is much more involved than the time taken to write the code for the project, the application can often require years of experience and quite possibly other routines previously written when weighed against the time and budget.  But to what end and to what extent do we reserve code before our clients no longer stands apart.