Code Naked

So I spent some time over the holidays working on my proof of concept framework. One of the key features I added was something I have always been curious about but never really got around to playing with, Dependency Injection. I thought the idea seemed to be powerful but I never really grokked it until I sat down and started to implement my own DI container. The first thing I did was hit google and search for "PHP Dependency Injection". It turns out there are a lot of frameworks out there now that support some form of injection but I wanted to make sure I was taking the best ideas from all of them and rolling them into my own. I decided to start with Constructor Injection as it is the easiest to implement, but I also wanted to introduce the concept of a context. One of the things we have to contend with frequently in software development is the transition of our code from development environments to production environments, I wanted my framework to knit itself together automatically for whatever environment it was being deployed in. For example, when I am in development I want my logger to use the FirePHP extension and have it log at the debug level. In production I want my logger to be completely silent for all but critical errors which are logged to a remote monitoring server. Most of the time I see this implemented in some form of Environment via an init call /** * Initializes the main logger * */ protected function _initLogger() { // logging handler $logger = new Zend_Log(); // general logger, in charge of writing important info to PHP_ERROR $stdWriter = new App_Log_Writer_Error(); $stdWriter->addFilter(Zend_Log::DEBUG); $stdWriter->addFilter(Zend_Log::INFO); // If we are not in production and not running from command line, // send logging info to FirePHP if (!$this->isProduction()) { // queries if ((bool) $this->getConfig()->log->writers->query->enabled) { $queries = new App_Log_Writer_Query( $this->getConfig()->log->writers->query->uri); $logger->addWriter($queries); $stdWriter->addFilter(9); } // firePHP if ((bool) $this->getConfig()->log->writers->firePHP->enabled) { $firePhp = new Zend_Log_Writer_Firebug(); $firePhp->addFilter(new Zend_Log_Filter_Priority(9, '!=')); $firePhp->setPriorityStyle(8, 'TABLE'); $logger->addWriter($firePhp); $stdWriter->addFilter(8); } // debug if ((bool) $this->getConfig()->log->writers->debug->enabled) { $queries = new App_Log_Writer_Debug( $this->getConfig()->log->writers->debug->uri); $logger->addWriter($queries); } } $logger->addWriter($stdWriter); Zend_Registry::set('logger', $logger); $this->_logger = $logger; } As you can see, there are a lot of implementation details that the environment needs to know about in order to get logging together. Even worse is the fact that if you need to get at the logger in code other than in the Environment class itself you need to get it from a registry every time $logger = Zend_Registry::get('logger'); Read More

The last part of my review of the book The Nomadic Developer: Surviving and Thriving in the World of Technology Consulting continues on from my third post by talking about how to Survive once you have your foot in the door of a development firm and then drawing some conclusions about the book itself.

Once you have started working for a company, you obviously want to remain employed with them for as long as possible. The section on surviving had many great information points, for example: People who create profit don't get fired. The real key to achieving this is by being the go-to person for a client. Preferably a big, fat, whale of a client. The odd thing with my current employer is that they wait for me to become available in order to have work done on their core business systems. Time tracking is a cornerstone that all other aspects of the company rest on, from profit projections to project performance metrics. There are several reasons the big Cs want me to work on this project; trust being at the forefront. The people who depend on this information know that I always say what I mean and that when things are on fire I am not going to leave them hanging. Another reason is that I don't bitch and complain (to them) about what a piece of crap the old legacy code is and how hard it is to work with. For me, I take pride in knowing that every source file I open has been made better in some way by the time I close it. Even if it's not actually related to the bug I am fixing. Not having to hear a developer complain is music to the ears of the project manager as well. Much like getting hired in the first place, the surest way to get assigned to a project is for that project's PM to ask for you specifically.

Another interesting point was that you should strive to not be overpaid. How do you know if you are overpaid? Well, you should be bringing in at least 1.4x your salary, if you aren't then your are being paid more than you are worth. This is a key issue, and one many people have not woken up to: for a business, who stays and who goes in tough times is all about money. I actually told a friend of mine Andy who has his own consulting firm EyeMagine Tech, that although I very much enjoyed working for his small shop, he could not afford to hire me at this time. He was a little disappointed at first (as was I) but after a brief time he actually thanked me for helping him see the business sense behind what I had said. It may seem ludicrous that I convinced a potential employer to not hire me, but you better believe that once he is big enough to afford my rate, he will be on the phone calling me for a position. This is the key to everything in consulting: Setting up the relationships that ensure you will be working for years to come. Read More

The third part of my review of the book The Nomadic Developer: Surviving and Thriving in the World of Technology Consulting continues on from my second post but focuses on the chapter that talks about what you need to ask before you join a firm. It may seem weird, but there are actually many reasons you might not want to join an organization. The obvious ones are related to pay and benefits but I found some of the questions were insightful for determining not only the enjoyment that I could experience working there but also the strength of the company for ensuring that I enjoy a long term contract before before having to hunt for another gig.

One of the key issues I find with my current employer is that they are not very transparent with their sales process. I am not sure if it is because they miss so many sales bids or if they are too busy to update everyone but I definitely think that there is a serious lack of information flowing from sales to the rest of the organization. This makes it hard to stay on top of the vision of the company. By knowing what projects a company is pitching for, you know where you should focus your learning efforts to stay on the cutting edge projects in your company. Two of the best questions they recommend you ask in my opinion were "Does the delivery organization work with sales to make sure estimates are realistic?" This is an important one to ask because knowing that you are going to miss your deadline before you even create your first source file is a very stressful situation. Having a sales team estimate blindly can be a real recipe for disaster. The other important question for me was in two parts "How are leads generated? What happens if a lead is generated by a consultant?" No brainer. Without solid leads your contractor butt is history. That being said, if you generate a lead it would be nice to get more than a free lunch and a pat on the back. Read More

The second part of my review of the book The Nomadic Developer: Surviving and Thriving in the World of Technology Consulting continues on from my first post concerns the portions of the book related to getting into a consulting firm.

There is a lot of common sense in the book, and although this chapter does have have a lot of ideas that fall into that vein. "Appearance Matters" and "Be easy to work with" are a perfect example of something that you shouldn't have to be told. There are some definite points that may developers need to remember. "Always be learning" is one of those suggestions that I wish many developers would take to heart. For me, this is not a difficult thing to do as it is the reason I was drawn to software development and technology in general. Things are always changing, and I like to constantly improve my techniques and skills. There are many in this industry though that joined it because of the promise of high-paying jobs. We can definitely earn high rates for what we do, but only if your skills are in demand. Some of the other points that stuck with me from this chapter are:

* Be active in your technical community
* Demonstrate good writing skills
* Develop your network

The last item is one of the main concepts of the book, and to be honest, this is the area that I need the greatest improvement in. This idea only makes sense to me since for most of my life I have gotten job by being personally recommended by someone I know. Let's face it, a good resume can be put together by anyone who has been in the industry for a couple of years. Having a quality person hand your resume into the person in responsible for filling the position is worth more than anyone you could write on the piece of paper.

The next part of this book review is important for knowing what you need to know in order to join a firm.

So I just finished reading The Nomadic Developer: Surviving and Thriving in the World of Technology Consulting and I thought I'd write up a quick book review on it to get back into the swing of things with my blog. The problem is, once I got started I ended up having a lot to say about this book and about my experiences as a technology consultant. I have decided to break the book review down into the main sections that I found useful from this book. I guess from the introduction you can surmise that I liked the book and that I am going to recommend that you get it. You would not be mistaken, but let me explain why.
Read More

I was really annoyed today by a seemingly harmless line in an email: Given the compressed timeline, we adopted an agile approach to the build.

I love it when a firm starts on a project with a crazy immovable deadline that they can't make if they have to waste time planning it and so they decide to use an "agile" development "process". The trouble of course is that they really mean they don't want to do any planning at all - not even a crappy waterfall process. Instead they spray tasks at developers and pray that they there are no scary things that are going to come and bite them in the eleventh hour. A project descending into chaos is usually a sign of a project that is about to fail as panic sets in. Setting out chaotic from the very start sounds like a project I do not want to be on.

Agile development does not mean throwing out all planning, it means forcing the client to choose what is really important to them. I have been on an agile project that basically built an entire website from the graphic artists design document. Then people wonder why no one knows what a particular button is for, and why it's not in everyone's copy of the jpg. Agile development also means making sure that each component is complete before moving on to the next task. I find that developers will sometimes not implement a feature such as sorting a list with the hope that it will be caught in QA and then they will essentially be able to extend your development time into the QA period. You sneaky little developer, you'd be cute if it wasn't for the fact that you are freaking out because you haven't slept in weeks and your family is starting to take the guy that mows your lawn out to do family things because you are never around.

Another key to the agile process is that the team remain flexible to client changes. Pushing code early and often is definitely the cornerstone of this process but if the client comes back after a code push with a whole mess of changes, where exactly is this time going to come from? Sadly it's another reason why you are not going to get to spend the weekend relaxing or bringing in the patio furniture before it snows ... ummm, be right back, I just remembered something I forgot to do. If you aren't the master of time and space then there is simply no way to do more work in the same amount of time which means you need to take weekends and evenings away from developers. This leads to burnout which hurts your team's productivity for the remainder of this project and most likely the next project they are on.

Then people wonder why the agile development process hurts so much. It's simple really, you've never used it before.