Ponderous Programmer

Agile Scrum / Project Boards

noreply@blogger.com (Joe Campbell) — Sun, 26 Jul 2009 17:00:00 +0000

So, as some of you all may know I am a proponent of agile methodologies. I have posted about agile in the past: here and here and possibly here - what you'll notice about those posts is that they are not specifically about agile, but rather about practices that I find important to doing my job well. This post is specifically about an agile practice and in specific about scrum and the practice of keeping a 'scrum board'

Physicality is king

A scrum amounts to a time boxed iteration of work. In this time box we are fixing the time, the money available (in the form of people) and we are allowing to vacillate the total amount of work that this particular group of people can accomplish (the features they will develop). The team when they start understands how much work they can complete and they commit to doing that many features from a list of features supplied to them. Then the work can begin. This work is 'tracked' as to its done-ness in either electronic form or in physical form. This should come as no surprise to anyone - but I am a large proponent of the physical scrum board.

The scrum board is a physical board used during the iteration to track the work (as mentioned above). Each story/feature gets a card on the board and is placed in the "ready" column. The other columns may vary depending on the team, our team has a "ready", an "in progress", a "done", an "accepted" and an "impeded" column. The cards are placed in each of these states as the feature is being worked on, meets its doneness criteria and is eventually placed into the accepted column.

What is great about this is being able to see and touch the cards or stickies. Doing this provides each team member with a sense of accountability that is not there when you attempt to just talk about features and work you are doing in the 'theoretical' during your scrum stand-ups. Having a physical board provides something that doesn't seem to be there in software solutions either unless you happen to have LARGE touchscreens (think Version One, Rally Dev, etc.) that provide that tactile, walk over and move the 'card' from one column to another, feel.

For me there is also something internally satisfying about really seeing items move from ready, to in-progress to done - Right there on the board. Without it, despite peoples updates, I feel a little lost during the iteration.

Additional (unintentional) Benefits

An additional benefit to the physical board is that is can be a great information radiator - transparent to anyone who happens by... they can see what you are working on, what you plan to be working on and what is already complete just by looking at the board. If an individual needs clarification they can always ask, but the board being out on the floor for everyone to see provides an ave for communication (despite being passive) that didn't exist before. It may generate questions, comments, or just plain discussion. Think about this situation - you are working on a feature in your sprint that interacts with another persons feature set (i.e. more then one team developing at a time) they happen by your board and notice what your team is working on and ask about how its going to integrate with what they are working on. Possible disaster averted due to this simple upfront conversation. Simply AWESOME.

A team can also use the physical board to add additional sprint metrics (information radiation) increasing the transparency with which the team is operating.

I fought the creation of this physical board for our team for a good long time - seeing what it can do to help the team, I am sorry that I fought as long as I did. The physical board seems to be an invaluable tool for the team and the organization at large.

PS: This physical board can also play into a Kanban type pull scenario - but may not include the specific columns mentioned here.

Another Bob Update

noreply@blogger.com (Joe Campbell) — Sun, 26 Jul 2009 16:09:00 +0000

Bob is now home from the hospital and is doing ok. Home care has been arranged for both Mona and Bob so that they have the needed support, at least in the short term for what is going on. There has been a hospital bed and an o2 machine delivered to the home and they are getting visits from the home care people on a regular basis to check up on Bob.

Bob is taking an appetite stimulant in an attempt to get him to eat more (it amounts to refined THC, the chemical in pot)... insert interesting munchies joke here. His intake of food and fluids however is still woefully slight. He is also been taken off the lasiks now that he has been released from the hospital. There is a good chance as well due to his insanely low blood pressure that they are going to remove the need to take his blood pressure medication as well. Which in all honesty is a good thing, one less pill to think about and one less chemical to float around in there. He remains on Plavix to help his circulation. His circulation is also poor and requires him to keep the house a little on the warm side (because he is consistently cold). Mo worked with him to help him layer clothing, etc. to help keep him warmer in his extremities.

This is prob. the last of the significant updates for now unless something bizarre happens or he worsens significantly.

Thank you ALL for your wonderful support, the checkins, the contact and well wishes. It was felt more by myself then it was for mo (as the calls generally came here to the house in NJ) but I will make sure to pass along all the well wishes to her.

People I would never have expected to send their care and good energies have done so in the past two weeks or so. It has been, enlightening and eye opening to me to see that. Thank you all for helping this family with support from yours.

Blessed Be,
Joe

My Wifes Father - update for family.

noreply@blogger.com (Joe Campbell) — Wed, 22 Jul 2009 19:22:00 +0000

Sorry about using my blog to do this, but this was the best way to get everyone I know informed as to the current state of affairs.

Mo's father has stage 4 lung cancer. His left lung has totally collapsed and due to the cancer in that lung (located in the pleura of the lung) the lung will not re-inflate. That lung's function (the left lung in Bob's case) is totally gone leaving the one good lung to do the work for him. The cancer Bob has is additionally in his liver. The cancer in the liver is essentially driving down Bob's desire to eat or drink enough fluids to keep himself 'right' while he is on lasiks to keep the one bad lung from filling with fluid.

On meeting with the oncologist this morning (7/22/09) - the oncologist did not recommend Chemo due to Bob's already diminished health and other pulmonary issues (PAD, etc) indicating that if Bob were more healthy to begin with then it might make sense because he would have some energy reserve to deal with the issues the chemo could bring on. He indicated that in cases such as this the bad side prognosis is 3 - 6 months. If chemo were an option, and Bob were prepared to fight he might get out to 10 months to a year or more but that would be the outside case.

In the end the picture is not rosy. We will be looking to organize in home care for him and Mona in the short term and further working on which long term plans and options are available to us all in order to make the best of a bad situation. The current state is mostly up to Bob - he has some control of his destiny here and can change his life style to make the most of what he has left. We are essentially in a 'wait and see' what he will choose to do. If this information significantly changes, please watch my facebook for further links and information.

Thanks,
Joe (On Behalf of the Campbell/Vercruysse Family)

I Hate Programming for the Web

noreply@blogger.com (Joe Campbell) — Fri, 26 Jun 2009 00:51:00 +0000

So I have really been thinking about this for a while now. I have had the chance to work on more then one web based project. I have also had the joy of attempting to write a website for just TWO browsers (in a time when there were essentially two well known ones, IE and Mozilla). I have come to the same conclusion each time I do it, I HATE writing "applications" for the web.

State (NO, not friggin' New Jersey or Pennsylvania)

Gripe number one, the web SESSION. This little beastie is meant to turn what is normally a stateless protocol (http or https) into a stateful one. It is meant to keep track of things on behalf of the client, on the server, for the purpose of making mere html pages seem as if they are an application. This session information makes the loosely coupled html pages hang together as if they were a full blown application. Depending on your platform a programmer can store just about anything that they can dream up into the session and then call it back at whim. So you might ask - what is so wrong with the idea of storing some of this information? One - it’s a bastardization, the web was never designed to have such a construct. Some smart people made it up to solve the problem of doing more "interesting" things with web sites. Two - it can if not done correctly, completely screw up and make pointless any load balancing you may want to do to make sure your web servers can handle the load of all the people attempting to hit your site at once. Lets be blunt, if you wanted a cohesive state (engine or otherwise), why didn't you just write an actual APPLICATION?

Standards - We don't need no friggin' standards

Gripe number two - HTML/CSS. Look these things are supposed to operate the same way no matter what 'interpreter' you use to parse and present the results of the markup that is HTML. Both of these things are supposed to be standards that leave little or no room for interpretation on what it is that they are supposed to represent or what they are supposed to do when they are parsed out to make a web page. However, as any web developer will tell you, there is ambiguity in the standard that then gets interpreted by a browser programmer and as such leads to the different browsers doing different things based on the EXACT SAME markup and CSS. What a FRIGGIN' PIA. FOR REAL? What you get out of this is needing to maintain more then one CSS for the different types of browsers, or to maintain different CSS markup in the same file for similar purpose. This is all done in the name of making the ONE web page you just wrote look the same no matter which browser it is being viewed in.

Singular deploy

Gripe number three, while it is true that I get to deploy the application just once, as you can see above - I might as well have deployed the application one time for each browser type I wanted to support. My code is different essentially for each one. Granted - a lot of the logic is deployed once (i.e. the dynamic stuff I am doing behind the 'presentation' that is a web page) so I'll give anyone that one no questions asked. The other thing of interest here - will things like the Apple Application Store bring back applications on the desktop? Think about it - a super easy to use, easy to deal with installation and management mechanism that has what amounts to a micro payment to purchase in a great number of cases. VERY interesting if you could make that system work on more then just the iPhone/iPod Touch.

Security

Gripe number four. The web is a huge pain in the ass when it comes to security of what it is that you are developing. There are phishing attacks, XSS, CSRF, and god knows how many other varieties of remote type attacks. There is injection of a variety of kinds to top everything off. Add to all of this stuff that you have to defend against on the server side you also have the security vulnerabilities in the browser to contend with as they may make any of the other styles of attack that much easier. Desktop applications may have a number of the same types of problems, but at least I can count on only having to solve them in the application and not having to deal with accounting for both a browsers issues as well as problems in my own code. All this in the name of not having to deal with remote installation of code. Lets just acknowledge that installing software and managing packages has gotten a lot better then it was and consider it when new projects come around. But we don't we stick with deploying things as 'websites' because that is what EVERYONE DOES. I would still at least consider, in a closed circuit, if doing something new as a web app (i.e. internally for a company) makes the most sense before embarking down that path. Think Customer Service application and ask yourself if it makes sense to be a web application. Really?

AJAX - Flash and other ilk

SO - IN THE NAME of all this is freakin' holy, because we want things on the web to act, look and feel more like applications on the desktop WE ADD things like flash, silverlight, ajax etc. These things essentially provide a 'framework' window in which to - wait for it - WRITE AN APPLICATION! Are we all certified morons? We are all OK with this - it might as well be a java applet for cryin' out loud. All of these things break browsers in some very fundamental ways because the URL that renders the page is now a meaningless bit of fluff, the forward and back buttons which worked wonderfully when all the web was stateless are also now meaningless because they all work on the context of a page - and all the flash, ajax and silverlight items do not. Talk about ass freakin' backwards. Lets take a browser and put an APPLICATION in it rather then a web page. All these items are designed to get more control over something that was specifically designed to be so much more light weight and easy to use.

URL Shortners

Talk about compounding issues - now on top of everything else we have a class of services that shorten URLs so that emails and Twitters and other such 'social media' items don't have to deal with super extra special long urls links in text. HELLO? FOR REAL? I think Jeff Atwood put it perfectly when he pointed out that an href in html or url tag in bbcode or what have you were specifically designed to SHORTEN THE ACTUAL url so that you could use a single word as a link if you wanted. These url shortners add another level of complexity for finding things on the web, they can't be indexed, the can't easily be searched - they are not descriptive - and lets not even discuss what the hell happens when the 'site' that is doing this additional translation of short URL into the real one gets compromised. Now ALL those short urls are taking people to places that are installing malware. Awesome.

Face it - the web is a giant mess. Yet we all seem to still so enamored with it and everything must have a 'spiffy' interactive, loginable web presence. When are going to wake up and truly solve the issues of attempting to make web applications be actual APPLICATIONS? I dunno, but I do know its going to continue to be a pain in my side for a long time to come.

It is the people, stupid...

noreply@blogger.com (Joe Campbell) — Wed, 22 Apr 2009 08:09:00 +0000

There has been a great deal of conversation in the world at large about different ways in which to perform work (i.e. processes for tracking and getting things done). There are many and varied ways in which this has been attempted - processes such as WATERFALL, SCRUM, AGILE, CMM, RATIONAL... all of which are about the same thing, attempts to make software development managable and predictable. Most of them however fail at their attempt for a variety of reasons, but I wanted to take a minute to focus in on one aspect of why they fail - The people involved.

The People

It should go without saying that process is really only a small part of how software development in any company gets done or executed. The process is in place to attempt to guide and assist when questions come up or there are issues found during development. These problems can be with the intent of a feature or sometimes even with the 'code' implementation itself. In this respect each one of the processes above meets the need - they can all provide some level of guidance for an individual or group attempting to develop software. However with the exception of the 'agile' stack a good number of them miss the point... process is not helpful in dealing with people. Real people are doing the development and real people are hard to predict for over time.

The Process

Every software project I have ever been involved with attempts in some way to be predictable in its delivery of items. Items for the project may include documentation, code or a myriad of other things but in general the 'what is delivered' only matters in so much as this discussion being about software development. Some projects focus on Dates (not these or these) the times during the project on which certain "items" within the project will be delivered. New functionality or even the entire system development might be driven by these dates. Sometimes these magic dates are called 'Milestones'. These milestones are points in the project when supposedly major portions or steps of the project will be considered done (most of the time without a clear definition of what 'DONE' is). Gantt charts, carefully laid plans, deadlines, etc. etc. etc. all put in place to suffice a process that in the end is attempting to control and make predictable the delivery of software. All are attempts to stay in control of something that in most cases by its very nature is 'out' of the control of the person doing the planning.

OK - so maybe that last statement is a little harsh. Lets be realistic though, I am sure everyone reading this blog has been on one project or another where the schedule, deadlines and all, in addition to what was 'TO BE DONE' in the given time frame was essentially dictated to them by either management or a project/program manager that was being told to essentially get 'X' thing done by 'X' date. Addmitedly the world is full of deadlines - and some deadlines are needed, but having two of three sides of a triangle dictated doesn't leave alot of room for the 'last' variable to move around alot.

But in the end we plod forward, bad news is supressed because no one wants to hear it... and then everyone ends up on a DEATH MARCH to the end of the project. Everyone gets irritated because the work they may be doing is not of the highest quality (in some cases even mediocre quality) and everyone feels dirty about not adhearing to best practices when it comes to development. There are no unit tests, the documentation is shotty - and the delivered "thing" is held together with spit and bailing wire.

MOST Processes miss the point its not about the deadlines, its about the people - and maximising what they can do to get the most delivered possible with the highest possible quality.
Agile and people - some implementors miss the point

Most processes I have worked with and in focus on variables that most people think of as being easily controlled. Things like the delivery date or the number of people working on the project. It is true that these things are easily modified and very measureable but the item that most project/program managers don't consider is what happens when you don't fiddle with those things but instead work to fully understand the work and how much of it the development team can actually accomplish CORRECTLY.

How gaining this knowledge helpful or different from what most methodologies do and tout? First, having this understanding is a very agile practice in my mind. WARNING BROAD SWEEPING STATEMENT FOLLOWS: Usually project and program managers understand what needs to be done, but they don't understand the constraints in the existing software or sometimes even the existing systems if we are discussing full life cycle systems development. This is where controlling the work list is important and priority is KING.

Agile processes are all about knowing the priority work list and what the people CAN accomplish. In essence it is all about the people involved (project and program managers included in the 'people involved'). Agile is about knowing what the people are capable of doing, producing a measurement of that (velocity) and using it as a way to understand how much work a given group is capable of in a time box. This turns the tables and empowers the people involved to push back and say no to things because they have a definative measure of what they are truely capable of accomplishing well and correctly. That is not to say that on occasion some teams will go above and beyond, but that doing so becomes a CHOICE and not a MANDATE because the speed of the team is no longer a variable and if it is - it tends to be a very predictable one.

Agile is all about the people. People understanding themselves and the people they work with. Understanding what each one of them does best and putting those things together to get a deployment of working software out the door. Agile is about making the software delivery as predictable as possible. Agile is about adding the right process to the people to allow for that predictability. Agile is not about imposing or over imposing but focuses in on the people involved and helps them with the right 'touch' and guidance, the right process. In that respect - agile process is the hippy of the software development world - one that I am more then willing to embrace because it is the people that matter. Without the people - nothing gets done and if you have a process that works well with the people and not counter to them I would argue you are going to get alot more done with people being generally happier about it.

Intra-Office Male Genitalia Mesurement

noreply@blogger.com (Joe Campbell) — Thu, 26 Mar 2009 23:40:00 +0000

Company A Purchases Company B

So this all starts innocently enough, one company seeing an opportunity to fill a gap in its own game plan purchases another perfectly running company, on the surface. The company doing the purchasing does their due diligence, reviews the books and game plan of the company they are planning on buying to make sure that everything seems like it is on the up and up. This whole process goes smoothly and everything seems to check out. The idea over all is awesome because it fills a hole that company A has in its offerings or business plans. The purchase moves forward.

The Excitement reaches a peek

Both companies are very happy that things are moving forward. The documents are being put together and everyone is having their lawyers look over and red line them. This is a time of satisfaction for both companies involved - a time of celebration. The final signed items are in and the purchase is complete. They are now a single company, this is when the measurements begin.

Making their mark

Company B (The purchased company) now starts to feel that they have to make an impression, show their metal and let everyone know that they have been very successful and that Company A purchased them for a reason. They try consistently to show how what they do in terms of development and process is the best thing since sliced bread. Company B goes out of their way to make sure that everyone knows that the way the do things has worked for them and they want Company A to know what their past experience and success is. This process does quite the opposite however and starts to make Company A staff think that Company B staff are pompous and think that they are better then everyone else. Both sides start to feel slighted and no one feels as if things are working smoothly.

My way or the high way

I once wrote about this very topic when I was talking about management but here, in this situation, it becomes a mechanism for how communications between both companies go. Company A thinks that they are right, Company B thinks that they are right and in the end - nothing productive gets done. If something productive gets done it is generally due to people pushing through their own personal preferences and differences and not because any of the communications or relations between the two companies have gotten any better. This posturing may eventually break down and one or more managers on either side step in and just lay down the law. This sometimes has a good effect and other times has the opposite feel. Without a solid direction of 'ownership' and decisions making however - this state of afairs gets set up to continue to repeat itself over and over and over with each project that is attempted that is inclusive of both sides.

Mine is bigger then yours

In the end the whole thing becomes some sort of bizarre mating ritual where both sides are whipping IT out and stating that theirs is the biggest in the room. In the end it breaks down into a childish US vs. THEM when it didn't need to.

What is gained? Nothing really... reality is that no one is going to get canned, ideas come and go but good people, when respected, stay. This makes for some of the best situations where really good things can happen if we just stand back and let them. Instead one or the other side feels as though they are being ignored or something else and bad blood builds and builds leading no where good. We spend more time measuring one another rather then just doing good work that we both know that we are capable of doing. Its a bit cliche but:

Can't we all just get along?

We need to stop measuring each others male genitalia and get down to doing the work that we both know we can, transparently, cohesively and without fear. Sharing all blemishes, pimples and high points in an attempt to pick the best of both sides and get the BEST possible answer for all rather then a semi good answer for one or the other.

Superfluous Features

noreply@blogger.com (Joe Campbell) — Tue, 24 Mar 2009 02:56:00 +0000

from: http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB0li?p=967

"Before going on I should like to explain why I may have objections to "superfluous features". Suppose that a machine contains a certain feature and that I can show, for instance, that it is impossible to use it intelligently or that its use gives rise to undesirable programming conventions; suppose furthermore that the defender of the design agrees to my objections but defends the feature by pointing out that, if I do not like the feature, I do not need to use it, implying that no harm can be done by something "extra". In that stage of the discussion I shall stress that the design would have been better without the feature under discussion. If it is impossible to use it intelligently every effort to do so is spoilt and the programmer would have been better off without it. If its use gives rise to undesirable programming conventions, also in that case the programmer had better ignore the feature completely."

I wrote a post a while back on some things being overly complicated in which I was talking about some new features being introduced into the java language. I think the above quote rather proves my point. If by adding a new feature you are claiming that only a select few people would be capable of using it and those who don't know how or wouldn't use it - Shouldn't, then you are adding something that should be considered superfluous. If the feature is impossible to use well or as intended - Why have it at all?

Agile, Agilsts and philsophy

noreply@blogger.com (Joe Campbell) — Tue, 24 Mar 2009 02:49:00 +0000

Being Agile

So I recently read an interesting article on the decline and fall of the agilists. I have to admit that it was an interesting read and it was not what I was expecting at all. I had decided on clicking the link that I was heading to read an article that was lambasting agile as a whole, and in specific the people who supposedly support and enable people to be agile in their enterprise. What I got was different. What I got was a point of view on people being far to rigid in their ideology, the agilists, the evangelists (supposedly) of the agile software development 'movement'. The point of view was decisive and accurate in my opinion, but not because agile is anything specifically different or the people who support it are any different - but because what I get out of it is an equation of an agilist to a terrorist or other extreamist.

Becoming an avid agile supporter

Over the years I have become a rather avid supporter of the agile methodologies. Scrum, XP and a few others have become the ways and methods that I would naturally choose to use when I attempt to do software development. These mthods are also the way in which I would hope that the business that I work for would choose to do their software development work. This of course is not always the case. Like most people I have worked for companies that have waterfall methodologies or other ways to do software development. These methods in some ways work for the companies that have adopted them. Sometimes they work very very well for those companies. They get alot done with their waterfall systems and feel that they have accomplished alot. It is my beliefe that even those companies could get more out of using agile methods. This makes me a supporter of agile, but it doesn't yet make me an agilist. It means that I would choose to attempt to talk the people I work with into giving agile methods a try - But I am not going to dictate that they need to do XP to be agile. More it is to describe that I am going to attempt to let people know what I have seen work in other places using my experience to try and allow a change to occur in the company. One that hopfully will get them to recognize a benefit.

The agilist in hiding

Does the desire to only use Agile methods make me an agilst. Possibly, but what I think differentiates me from the agilsts that are pointed out in the article is that I don't support doing agile in one set and unchanging way. One of the tenants of the agile movement is that the process has to be about the 'people' involved - the individuals and interactions before the processes and tools. You always have to start with the people. You have to look at what the people do, see how they move day to day and attempt to help them along a path. as an agilst I attempt to provide guidance and support for any given company finding their 'own' path. In a number of cases these choices will be what I recommend - but in a great number they will not. These other company(s) will need help finding their own path. This is when the agilist must become a person that helps to maintain the 'spirit' of the manifesto... attempts to provide guidance for the decision making process rather then dictating that things be done in a specific way.

Being an agilst is all about the philosophy

Being an agilist is all about the philsophy held - its all about the people involved. Its about nurturing the good processes and tools in support of the people and interactions. Being an agilist is not dictating that it must be some 'ONE MAGIC' way. People that attempt to make being agile all about being one specific way are looking for a magic bullet (a silver one perhaps). In the end however we all know there isn't one. Development of software is sufficently chaotic that having bumpers is better then knowing the one true path. Having guidlines rather then mandates... having a person who is willing to guide rather then dictate can be helpful. The aim is to move forward the best way we know how given the situation, I personally believe that being an agile organization is important to 'grow' how software is developed. I am an agilist in my heart, but certainly not the one that Mr. Appelo describes. I hope never to fall into that trap and become a cult leader for agile.

Process, progress and equality

noreply@blogger.com (Joe Campbell) — Sun, 01 Feb 2009 21:15:00 +0000

So a friend of mine Mr. Fury recently wrote a little post on "Process" (Yup, thats capitol P process). Specifically, since he and I work for the same Big Co., we was writing about a wonderful framed master piece that hangs on a number of walls at Big Co. This art piece, which he points out, is meant to be inspiring and up lifting is a bit off the mark and is a bit mocking rather then inspiring and uplifting. This picture says simply "Process = Progress", I think attempting to indicate that we are not moving forward @ Big Co. unless there is a process in place. It may also indicate that progress can not be measured without a process - but I am not sure that is the direct meaning.

Now - I admit, that I share some of the sentiment that was expressed by Mr. Fury on this one: process = progress seems to be a little off the mark in the situation that he describes. To the point where for a little while when I would see this supposedly inspirational picture hanging around our building I would take a black Dry Erase marker and add the programmers negation to it ("!=") placing an exclamation mark in front of the equals sign. Thus changing the equation from a equals to a "not equals". However as I think about this situation even more, even the not is a little overkill (just moving to the other extreme).

The Bad
Process used as a shield against new work or used as a way to send people into a wait state - or cause them to circle because they have not paid homage to the process is using it in a way that it should never be intended. Those people are using process to attempt to slow things down because they are overloaded, overworked or just plain a pain in the ass. In any case - it certainly does not equal progress, quite the opposite in fact.

In this sense - I agree with Mr. Fury because he pointed out in his case that the process was getting in the way. In fact it was adding additional time and drag to what he was attempting to get done. In a number of ways this is doing process for the sake of doing it and not because it is adding value to the job or the work being done. Sometimes it is tolerable to allow process to add a 'factor' onto work being done, but when the additional work being done really feels like it is busy work, or work gone to waste - that process should be dropped or changed it is no longer achieving whatever the process' original goal was.

I liken this bad state of process to the current state of Unions. When you are 'not permitted' to do something as simple as plugging your laptop into a network port in a building because that is a 'union job', that is process for the sake of process and is just plain stupid.

The Good
Process that helps communicate amongst many and various groups inside of Big Co. This is the equality that I think the picture is attempting to draw out. As a company grows it will have need to attempt to keep a bunch of separate units all on the same page. The increasing size of any company makes this increasingly difficult. In this case a little process can help and be beneficial. The caveat that I make is that the process needs to be defined and agreed to by both sides of a given communication and has to be helpful to them both. This decision to add process then needs to be revisited on a semi-regular basis to verify that the process has not grown stale and the need for it long since gone away. Only here do I think that process = progress - using process to help progress.

Overall - I am not sure the direct equality makes sense even with my definition for "The Good". A little process doesn't hurt where it makes sense - but when the process goes bad or is dragging other things down by adding to much time to getting something done, that process should be reworked or at least revisited. In these cases process is getting in the way of doing what Big Co. should be doing - which is the work of the company for the customer. Missing that mark overall is tantamount to failure as a whole.

Sorry about the quiet period...

noreply@blogger.com (Joe Campbell) — Wed, 09 Jul 2008 02:49:00 +0000

Sorry about the quiet period - it has been a very busy few months for me personally. Trying to understand and define what architecture is for me and the company I work for as well as taking 2 weeks vacation to sunshine filled areas. I have a few posts coming - the first one was just posted.

- A post continuing on the idea of architecture individuals being involved in some day to day programming (or at least having a task or two to accomplish for the programmers/infrastructure folk)

- A post about where I am right now and looking for potential guidance - basically a brain dump of my current thinking

- A post on attempting to ingrain security and testing into what programmers do from day to day

At least these are the ideas bouncing around in my head.

Interviews and the New Hire

noreply@blogger.com (Joe Campbell) — Wed, 09 Jul 2008 00:32:00 +0000

There has been a lot of posting in the past about what peoples favorite interview question, problem, poser, situation are. Some have even gone so far as to offer descriptions and tips of what to do if you are looking for jobs using head hunters, or provide guidance if you are personally heading to an interview with Google. All of these articles are focused on attempting to discover, in advance, if the person that you are contemplating bring into your organization, startup, Big Co, team or what have you has the chops to do the work. Or if you are like most programmers the new hire is of your caliber or better (although in most cases programmers are not about hiring someone who could possibly show them up which is a short coming in most programmers).

So I wanted to offer an alternative to this point of view. The point of view I am talking about is that all the 'discovery' in hiring someone has to be done before they are made an offer to work for your company. Specifically I wanted to float the idea that the first 90 days (which in most larger companies is the 'trial' period) the time in which the company will evaluate you overall, hopefully spend time hand holding you to help you find your way around the Big Co. hallways also be used to help you determine if the person has the skills needed to do the job at hand.

How exactly can you use this first 90 days to you advantage when attempting to help determine if a new hire has the chops to do the job? I think the single biggest way that this can be accomplished is to prevent new hires from being able to commit code directly to the source tree in that first 90 days. Big Co. or your company should look at the new hires as being still 80% unknowns. There is no telling if the new hire will be overly complex in their code, not follow the company standards, or just plain suck.

I have personally run into the "just plain suck" situation when interviewing people - I personally interviewed an individual that seemed perfectly good on the surface. In the interview he had all the right technical answers - but when it came to actually implementing something all the implementations were mostly done but never complete and they were always buggy and HE WOULD ALWAYS COMMIT THEM to the source tree - which would of course break the build for everyone else. Eventually we had to revoke his commit privilege which lead directly to his quiting.

So here I am saying that while the company decides if you are a good working person - the developers should also be attempting to decide if you can really do the things you said you could do in an interview. For the first 90 days new hires should have a senior shadow - and they should NOT have commit privilege. They should be forced into submitting patches to the code through their company programming mentor.

This has a few benefits:
1) It forces a peer review of the code before it gets into the source tree allowing for a greater discussion about solutions, the why and how of what the programmer new hire has done.

2) It gives the Big Co. programmers the ability to essentially have another way of evaluating the new hire for ability and skill and to really validate if they are a fit.

3) Because in the first 90 days most folk can be fired for almost no provocation it is easier to dump someone who might be a half performer - or might not be the programmer you thought they were before they get ingrained and are near impossible to get rid of.

I know in the end that I would personally have a hard time with this idea myself - but I think I could live with this over taking a test, or other challenge in an attempt to prove what I can do. Just let me PROVE it for real - let me live or die by my own abilities. Both for the company and for myself... I think it could make the whole hiring process better.

Over complication?

noreply@blogger.com (Joe Campbell) — Wed, 14 May 2008 12:13:00 +0000

I was reading one of the links that I get as RSS sent from Ragawald today about JSR-308 (What hath java wrought). This JSR describes some additional annotation on types that would extend the java type system allowing the compiler to do some more static checking work for me. There was a further breakdown explanation that was linked off the "What hath java wrought" article that is also worth reading for a good background on what this JSR could translate into. The additional write up is on Wide Awake Developers titled When Should You Jump? JSR 308. That's When.

Dynamic vs. Static

SO - I took a little dive down The Rabbit Hole, as I am apt to do, and followed a bunch of links on JSR-308. To be perfectly honest I am greatly disturbed by the information that I found. There has been a great deal of discussion about Dynamic languages, static languages and languages that are mostly static taking on some of the dynamic language goodnesses (or vise versa). Both sides (static and dynamic) have some relativly cogent arguments about why their thing-a-ma-gigger should be the one that means the most to the most programmers. Personally, as I have stated in the past, I am a "use the best tool for the job" type of person. Not only that, but I tend to try to bring in the stylistic flavor of other languages into the language I am using at the time, often mixing styles and metaphores as I go. Both arguments are powerful and at the same time equally pointless in the face of just being simple and getting done what you need to get done.

So, in terms of the JSR specifically, let me say that I am disappointed because the JSR I don't think is bringing anything of intrinsic value to the java language. This may be because I am looking for inherntly simple things or it may just be that I am personally a simpleton but lets assume that I give / gave myself the benefit of the doubt in this case. The title of the JSR-308 says the following:

"JSR 308, “Annotations on Java Types”, enriches the Java annotation system"

which I will admit on the surface seems simple, but it SOOOOO very much implies so much more. This JSR would allow the common coder to add annotations on java types and even further would allow the common coder to supply an annotation to a generic type as well. Some people would consider this to be progress... I am personally not so sure. Take the following example shamlessly pilfered from the "Wide Awake Developers" site:

void marshal(@Readonly Object jaxbElement, @Mutable Writer writer) @Readonly { ... }

Can someone please explain to me what this line would mean to some other class in my code? Better yet can someone please explain what are the potential outcomes of having a line like this in my code in an effort to "improve" my overall codebase?

If I had to guess someone can probably explain to me that the @Readonly is telling me that jaxbElement will not change in the method context. They can tell me that @Mutable is telling me that the 'writer' variable will change in the method context and that the second @Readonly is telling me that the method itself can only be called by something else that is also marked as @Readonly. Holy CRAP is that an amazing amount to remember about a single method.

Now I can hear a bunch of people sputtering that this feature would eventually find its way into being managed by the IDE's we may all use and love. I personally say that even if it does, that the value introduced by these new annotations is/will be lost on most people.

K.I.S.S.

One of the first things that I learned in programming and IT in general is that one should always keep a level head and try to look for the simple explanations and simple ways of doing something first. Keep It Simple Stupid is what I was always told. I came to understand that for the most part this old adage holds true. Granted that there are times where it is not always possible to do, maybe it is a particularly hard algorithm that needs implementing or other such item - but even in those cases attempting to be as straight forward as possible will help the person that follows you up in attempting to maintain and support the code. The addition of these new type annotations I do not think is in the vein of KISS. I think that this new JSR is about attempting to solve an ever smaller set of 'potential' coding issues (bad nulls, modifying variables you didn't intend and the like). The value proposition I just don't feel is there.

Specifically I think that this JSR is heading in the wrong direction. While most newer languages these days are heading in the direction of being more dynamic, more human readable and human understandable - this annotation JSR moves java in the other direction. We all know programming is hard but do we really need to make it even more so with something like this? This JSR raises the barrier to understanding what the code is doing in my opinion, lowering the overall understanding of java programmers of how their system works. Keep in mind that we have some other already complex things to solve... things like understanding multithreading and keywords like volatile better, maybe even adding some better multicore-multithreading support into the language... instead and to my dismay we as a community are out there attempting to solve a little niche of a problem. Granted the types of problems that this can solve are plenty hard to find and debug - but for an experienced programmer they are a small amount of an overall codebase.

SOOOO... How does one interpret...

Think about the interpretation of the example line I provided. I once said programming and being intuitive was all about memory / context - the idea of being able to hold in active memory about 7 +- 2 things, if I have to hold onto MORE then 7 items just to interpret what a singular statement is attempting to do and not even a statement per se. but a method declaration - I believe that I have bastardized the language. Why work to make it so hard for someone to just "Grok" what is being done that it is not worth the time it may take to learn to use the new feature. I would venture to say that it may be so hard to use this potential new feature 'correctly' that most people will just skip it altogether, being intent on what they know and understand. It will take the avg. person so long to make good use of the new feature that the language may be long dead before someone really makes it part of the main stream of development in java.

Should people start to think about learning a new language? I am not sure if that is the message I would want to convey (the blogs I linked in the first part of this message think so). I would rather convey that there is power in numbers and power in voices - if you like me think that this is a rather SORRY direction for the language to be heading in over all... SPEAK UP and say so. Send sun messages, get involved in the JSR project and get this sort of thing derailed before it starts. Other wise, the language you are working in right now my go the way of M code, or Cobol.

Stylistic Intuition - Or not!

noreply@blogger.com (Joe Campbell) — Tue, 06 May 2008 20:32:00 +0000

A fair friend of mine Raganwald wrote a post on the word "intuitive" stating that at least as it applies to programming languages it just isn't (i.e. it doesn't apply). A similar topic came up at work @ Big Co. in the last week or two in the form of something that company has not had to date... a coding style guide and a list of coder guidelines for how common tasks are performed in code at Big Co.

Perception is Reality

Intuitive means different things to different people. Something that is intuitive is really all about how the person looking at a particular item sees that item. As raganwald put it:

"And this is why it [the word intuitive] is not a very helpful word. Like good design, it means different things to different people."

it seems that this point about it meaning different things to different people is where Big Co. programmers are currently caught up. There are a number of people that have stated that the idea of having a coding 'guide' as well as a best practices guide is just a waste of time. Some have also said that the time spent on this endeavor and the time that may be spent on 'enforcing' a standard are wasted. Specifically that Big Co. programmers should be spending their time working at making things simpler or bringing about more simplicity in the code base. While I agree with the idea that Big Co. programmers and architects should be attempting to make the code simpler I disagree that setting a standard and having guidelines is wasted effort - for the "intuitive" reasons spelled out in raganwald's post. Some other things do come to mind that I think make the effort of value as well.

Memory - Value in commonality

Style guides for source code and guidelines for common programming boilerplate tasks do have value. Specifically they have the value of allowing programmers to "study" what the Big Co. code base looks like. This is important in the same way that updating sections of the code base is, its all about peeling the onion. Everyone has the ability to hold a limited number of things in their head when they are performing a task. Studies have shown that in general the number of things a person can hold in their active memory is about 7 +- 2 items. If all the code @ Big Co. follows a similar guide, I can reduce the number of interpretations I have to make between what my 'intuitive' code structure might be, or the way I may have learned it and over time train myself to expect things in a certain way no matter what type of code I look at when working @ Big Co. Once the 'learning' has occurred it is no longer one of the things I have to hold in active memory when performing a task. The learning has made code style and guidelines something that is automatic and basic ala. training someone to do a repetitive job well allowing room in active memory for other items, like classes related to what I am coding now or refactoring currently.

Programmer Ramp up

The style guides and other boilerplate guides also have value for new hires. New programmers starting at any new job almost always ask for any documentation they can get as well as for access to the source code. The first I assume to be an effort to see how "mature" the company is while garnering information. The latter I see as a way of investigating to see if the code is 'intuitive' to them. If you were to give the new programmer, both the code and the guide - they can level set their expectations ahead of time and possibly get started on things faster then that may have otherwise. The guides and guidelines can provide a needed context that a new programmer @ Big Co. might not get nor see if every new class file they open has a different look and feel. Couldn't all the programmers in the organization be faster if they knew in advance what to expect rather then letting each new source file be a style surprise? It should also be noted that there is something to be said here about not giving new hires immediate 'write/commit' access to the source tree but that is a post for a different time.

Simplicity

Style guides drive simplicity for everyone as well. If there is a common set of guides most IDE's and a good number of text editors these days will allow for configuration. It should be more then reasonable to expect that 'configs' for the commonly used tools in the organization (and even some of the one offs) are available to make the formatting easy. Even if you the singular programmer want to have a different or DO HAVE a different way that you need to look at the source code, there is a step by which you can have your environment of choice put the file back into the 'accepted' guide/standard for the organization. In many respects I consider it more lazy to NOT follow some standard then TO follow one. You could even consider it something I consider a service to my fellow programmer.

I think in the end - a weeks worth of fighting about some things I think is worth it in the end. If I save Big Co. developers 5 minutes of time overall / day it could add up to a significant amount of time saved over time. There is always a point of diminishing returns, but I don't think that this topic is one of them.

The Rabbit Hole

noreply@blogger.com (Joe Campbell) — Fri, 02 May 2008 00:14:00 +0000

I found my self in an interesting conversation just the other day about the commonly and oft wrongly used term for a position in Big Co. called the 'Architect' or 'Software Architect' or 'System Architect', you pick your poison. These days the term 'architect' is over assigned, over used, and overloaded to mean someone that has been in the programming or software development industries for an extended period of time. 'Architect' is being used to indicate that the individuals time 'IN' should equate to them knowing what they are doing and as such that they should be able to 'architect' a good system, or at best design a bit of software now and again from scratch. In the end, this over use and overloading of the word leads to misunderstandings and misinterpretations, and I ran into one in the form of an interesting debate question:

Should an architect also be a coder?

At first I was quick to answer this question in a simple and unequivocal manner: YES!

Then I stopped and thought about the reason for asking the question in the first place and the premise for thinking that an 'architect' should not be involved in any code base, or involved in producing any code for a given system. I then provided what I thought to be a more complete argument then simply answering yes. It went something like:

How can an organization, or any given programmer, expect to have a person or persons be responsible for helping set an over all direction for a system(s) without knowing what it is made of? As a programmer I find out what a given bit of software is made of by digging in and checking out how it is coded. I look to see what the codebase would be capable of doing, what it is resilient against, what code smells might it have - what the over all feel of the code is. I can think of no better way to help set direction and I find it difficult to see the other side which states the 'architects' like managers should not be interested nor involved in how the code is written. That they should only be interested in the high level direction - and that should be their only responsibility. I turned the counter argument in my head into something that I don't like architecture groups to do - and that is to become Ivory towers, or worse yet 'Picture-tecture" groups.

I firmly believe that architects should be involved in code... they should have coding tasks in each and every scrum/sprint/dev cycle (Insert term of choice for your company here). Only in this way can they truly understand the issues and problems and come up with creative and innovative ways to solve them. You might be able to find a unique individual out there who can just "KNOW" a system by hearing it be described - but to me that sounds more like a miracle person then someone I would care to get to know OR take any direction from.

In alot of ways I would hope that an architect would be 'OK' eating their own dog food now and again and being involved in implementing some of the things that they may have at one time put down on paper for someone in a meeting or design session. In essence I think all architects should be ok chasing items down the rabbit hole now and again. Its good for the soul, its good for development and its a spectacular sign that you have someone that is REALLY interested in understanding what they are talking about. An architect interested in a full understanding is what I want - not someone who just thinks they are the shiznit, or like Joel recently posted is an 'Architect Astronaut' or even better someone who is 100% enamored with the title of a blog post. I want to be someone who does really work and ACTUALLY helps programmers solve real problems that let them be faster, and get more done with less effort. I want to chase items down the rabbit hole once and a while - stay sharp and keep current.

Peeling the onion

noreply@blogger.com (Joe Campbell) — Wed, 02 Apr 2008 14:36:00 +0000

A post recently got me thinking about the topic of when it is a good idea to either revisit, rework or at the very least rehash an older "decided" on piece of code in order to make sure that all sections of an application are getting attention. Couple of thoughts around this that stuck me.

Re-visitation

One of the things that I like to do as a programmer is go over other code within a system (especially if it was not originally written by me) and work to understand it. This can sometime be a large and arduous task given the size of some system and the length of time that they have been in production. In the case of really large systems I may take a certain sub-section of the larger whole and attempt to understand just that. My tendency is to do this both on my own and as a result of being asked to 'work' on a given section of the application. Over all I think that this helps me to get a better picture of what the application is doing and can help me to refactor, when needed, to make the system more resilient.

7 +- 2

The above can sometimes be complicated by the fact that despite efforts most people can only hold in their head about 7 plus or minus 2 items or ideas or thoughts. Its a memory thing that is well proven. This point matters the most when you think about how you work on a section of a large application. At any point in time you may be making a spot fix (remembering 1 or 2 points of the application) or a sweeping type of change (attempting to remember how 5-6 or more modules work in concert to get work done). The larger the change you are aiming for the more information that you have to hold in your head. This can get even more complicated the larger the system and or the larger the change attempting to be made.

Pulling back the covers

So with each new dive into the code I get to uncover something that I didn't know and something that potentially I have to 'remember' when I am working in the codebase. One of the things that I love to see is that things that I 'assume' I can take for granted - I can actually take for granted. What I mean is - in working with any code base I have to come at it with a few assumptions and let the code prove me wrong. As a for instance I usually assume that something like connection pooling to a database works in a certain way (ways in which I have seen it work in the past, or ways in which tooling I have used in the past has taught me to think about connection pooling) when the system shows me that it does something different I have to increase the number of things to remember when doing work by 1.

Why memory matters

Programming should let framework be framework and business code be business code. When the code is different then common assumptions and works in a way that is not 'worldly intuitive' (intuitive here meaning in a widely accepted way in the world, knowing that the word intuitive isn't) it means I have one more thing I need to keep in my head when working in the code base. When the code base is really large there are somethings that I would rather not have to worry about. Connection pooling would be one of them. I would want to know that I can grab a connection from the pool and do work in a standard way and then return the connection to the pool. I don't want to have to know that it also performs acrobatics to protect me from not closing resources, or monitors what I am doing or even that it supports the color RED in a new and special way.

No decision should be forever

So, memory, change and refactoring all very important in my mind in thinking about programming. Since I am also a proponent of agile (scrum in particular) I support the idea of constant refactoring as well. I want to always make sure the code I am touching can be resilient to making large changes and always will move in response to the business and the way the business wants the system to work while minimizing the amount of work needing to be put it in to make it do what the business would like. Constant revision and constant eyes make things better over time. Previous decisions may or may not make sense NOW in comparison to when they were made.

Memory is one reason people may suggest changing something, having worked with a tool in the past may be a reason as well. You may even find that people are suggesting certain things based on what they feel is best for the overall codebase. What you can't do is dismiss the efforts to change with the following:

"...And if you don’t even understand what is in place now, then you’re simply not qualified to be suggesting that we move to something standard."

There are different levels of change and different levels of understanding... what is intuitive to one may not be for another. I am not suggesting at all that you dumb down the code to the lowest common denominator - but I am certainly suggesting that when you get enough people saying that something doesn't make sense it might be time to remove that one extra item from memory so that they can get on with making changes that matter.

My Years of Experience - An Interview Gone Wrong

noreply@blogger.com (Joe Campbell) — Mon, 24 Mar 2008 17:56:00 +0000

so I am just now catching up with some posting that I was fixing to do some time ago. I was reading an interesting article over at Coding Horror pertaining to the myth that when hiring someone it really matters how many years experience that they have listed on their resume. I have to say that for a variety of reasons I could not agree with the premise of this post more. Lemme provide a little background on my last search for a position:

The Setup

I was out shopping for a job and decided this time that I would give a head hunting company a try. I know, I can hear lots of people yelling "NOOOOOOOOOOOOOOOO why would you do such a stupid thing" don't worry, in this case I got one of the "good" companies (JSync). JSync in this case told me that they had several positions currently hiring - one of the opportunities was a position at the Philadelphia Stock Exchange. It seemed like it would be an interesting and challenging place to work. It also seemed as if the description of the position was exactly what I was looking for, the PSE was looking for a talented Java engineer that had X number of years experience with a smattering of other experience required (tomcat and a few other items included) I personally and reflexively skimmed over the total years required and moved right into the things that I didn't have background in to validate that I could learn them without too much effort all seemed in good order as far as I was concerned. JSync set up a PHONE SCREEN that turned out to be anything but.

The Call

The call started while I was out on lunch (specifically because I did not want to have that conversation in the same building I was working at to avoid conflict of interest and all that). The conversation start out well introductions and pleasantries aside the tech guys started their questioning. The questions started out small and my expectation was that they were going to get bigger, instead the questions dove ever increasingly into the extremely minor details of certain items. PSE was interested in the minutia and academia about java and tomcat and a whole bunch of other items. I was one the phone for over an hour. I finally had to stop the interview/phone screen and thank them for taking the time to talk to me but it did not sound like I was the person they were looking for. I interpreted that experience to say that they were interested in someone with either more experience OR someone who knew things that are easily found in a book or on the web. What they seemed not interested in was my ability to learn and self start. Rather then be interested in the process that I go through to gain knowledge in new technology and process.

Jeff states in his article:
"what software developers do best is learn. Employers should be looking for passionate, driven, flexible self-educators who have a proven ability to code in whatever language -- and serving them up interesting projects they can engage with."

This is what I think the interview, er, um, I mean phone screen at PSE should have been attempting to ferret out. Can I learn what I need to in order to do the job that the PSE would need me to do. Their screening process, I do not think, came anywhere even close and as a result left me feeling like the interview was a bust overall. I neither got the job or an offer, I just didn't measure up to their 'experience expectations'.

So if you are in a hiring mode what would you rather have - someone that has experience in software programming or someone who can pick up and use anything with ease and speed when the task at hand calls for it. Would you rather have someone stuck in their way of doing things or someone who can utilize any tool to approach and solve the problem at hand.

Jeff notes:
"No matter how many years of "experience" another programmer has under their belt, there's about even odds that they have no idea what they're doing. This is why working programmers quickly learn to view their peers with a degree of world-weary skepticism. Perhaps it's the only rational response when the disconnect between experience and skill is so pervasive in the field of software engineering."

So like Jeff I pose the question, if you are looking for a job, why would you want to approach a company who is still using the 'years of experience myth' to do their job posting and searching. Like Jeff I find the attempt to be a simply ignorant move to weed out people that the companies think are all fluff and no stuff. Rather you should look for companies are searching for passionate people with a desire to learn. Companies should look for people that have a modicum of experience (6 months to a year) and consider their full experience as a programmer, the "learning range" of the person they are attempting to hire and search for excellence in that area.

In the end if your looking for a job, you'll be much happier and satisfied with the interview when the items above are what the company is interested in... if you are the company doing the hiring you will be much more pleased with the result of your hiring efforts when it comes down to doing actual work in new and creative ways.

To Tree or not to Tree that is the Big Co Question

noreply@blogger.com (Joe Campbell) — Sat, 22 Mar 2008 02:46:00 +0000

I have talked about innovation on this blog before but a book that I have been reading and a recent post by Paul Graham stating You were not meant to have a boss got me to thinking about the topic of innovation as it pertains to management.

Paul says that there are consequences that happen when any company gets big. I believe he was pointing out that there may be a tipping point to the size of a company at which time the standard way of thinking about organization and management starts to break down leading to an inevitable slow down of everything that the Big Co. is attempting to do. He says the following:

"...companies will inevitably slow down as they grow larger, no matter how hard they try to keep their startup mojo. It's a consequence of the tree structure [of management] that every large organization is forced to adopt."

So my question(s) are thus: IS this tree structure, the org chart, really a necessity of getting bigger as a company? Is there really no innovation to be had in how companies organize themselves and the tasks at hand such that the 'tree' is the only way to go? My answer is NO on both counts - there is some empirical evidence for this in the world so let me see if I can back up my answer.

Ah the wizdom of crowds

Crowds as a whole are really quite something; they have a mentality all there own. One of the things about crowds is that they are really really good estimators. They are good estimators because no one person in the crowd has to be dead on they just have to be close. Taking a look across a broad range of answers to a given problem almost certainly provides a more accurate picture then having a few people (managers) making all the 'big decisions' for a company. This should be self obvious as just common place statistics yet every company I know is set up in the reverse and pays little attention to information to be 'gathered from the masses'. Provided the right information disseminated across a large group of people in an effort to estimate say growth of a sales unit within Big Co. the avg. answer has a much better chance to be closer to reality then the answer that a single smaller group of managers might be. There are a number of reasons for this, not the least of which is the pure and simple fact that the managers of a big co. by and large do not have all the information that may be needed to make an accurate estimate. You could argue that it is possible for the management folk to gather this information, my counter is that the instant it is gathered it might not be pertinent to the estimate. Only the frontline employees have a good feel for certain types of things, thus making them good estimators for a whole plethora of items. Big Co. being typical in most cases will however ignore the wisdom of the crowd in favor of a select few. This is a good case for not organizing in a tree and utilizing the information of the people to get things done. Those people however are going to need additional information that typical management holds tight to the vest.

Free and available Information

Information control is one of the ways that management types can maintain the tree structure and the management dogma. However the free and available information about all corners of Big Co. might spark a line of thinking in someone bringing about ideas that management might not other wise have thought of. Information pertaining to budgeting, staffing, pricing, sales and product can be very useful tools to the entire company. There is however an unwritten rule that this information is reserved for the management elite, those who have been shown to make good decisions in the past. What if those management types were armed with an army of people backing them up? What if that army had the same information management did and were allowed to essentially do what Paul says people (programmers in particular) do best which is invent new things rather then what is typical in Big Co. which is a stifling of what could be great new ideas:

"If you're not allowed to implement new ideas, you stop having them. And vice versa: when you can do whatever you want, you have more ideas about what to do."

All ideas should be welcome, radical ones perhaps more so. However if you lack the information about what direction you want to go in or where there have been problems in the past your new idea could meet with roadblocks and other preventative items. Information, good information is at the base of a great number of really great ideas. Share it far and wide.

Being Democratic

One of the HUGE draw backs to the way in which most large organizations is put together is the tree, the non-democratic way in which people are put into management positions. In a great number of cases people are promoted because they have pleased a singular person - their boss. In reality the person promoted might actually be a complete and total ass but that information did not weigh into the decision because only a small handful of people were involved in the promotion decision. In this particular case it might be an individual’s boss and that bosses boss who made the final call. You could argue that better managers of course might talk to people that have worked with said ass before but the tree structure of it all has the tendency to force that idea to the back burner as unnecessary. Be democratic, just like with the freedom of information and let everyone see what everyone else’s ideas are. Let everyone have a vote on what the company should be doing to increase profits, cut costs etc. Let everyone suggest what the best way to get and retain customers is. Let everyone have a vote. There is certainly no harm in letting the masses vote - you may just find that their wisdom was well worth a small effort to solicit the feed back in the first place.

Challenging Dogma

The problem with most of the items above is that they all challenge the dogma in management and organizational structure that has existed in companies now for a long time. There is some evidence in the world that this dogma can be changed (Whole foods employee based store management as an example) but there is certainly not enough of this type of trend setting work being done. Is the tree the only way? is it the case that your ability to change a company from within is limited based on where you are in the tree as Paul points out:

"...when you're part of an organization whose structure gives each person freedom in inverse proportion to the size of the tree, you're going to face resistance when you do something new."

I say the tree is not the only way; the items above should point that out. There are ways to organize that allow people to feel empowered to make decisions. There are ways in which Big Co. can allow people to THINK and ACT and INNOVATE to keep the company fast. It is however going to take changes in how management thinks to get there. Go Grass roots - take the discussion to the masses let us innovate management and eliminate the 'boss' as Paul thinks of it today.

"Here there be Dragons"

noreply@blogger.com (Joe Campbell) — Sat, 08 Mar 2008 16:14:00 +0000

The title of this post "Here there be Dragons" is what cartographers used to put on maps to indicate a location or place that they either didn't know or had not been mapped by anyone at the date/time their map was created. This wonderful line was also used recently by a speaker that I know so I thought I would bring it up here as a way to make a posting point.

Life in general is a large and wondrous thing. The world is big and there are so many things to do and see that one might reasonably expect to only do or accomplish some percentage of 'everything' within their given life time. Life is also a very scary place, with lots of unknowns and lots of places that should be labeled "Here there be Dragons." The world of programming in a large number of ways is also big and full of unknowns and places that should be labeled "Here there be Dragons."

The title, on seeing it written on a map of old would evoke feelings of fear and apprehension in the sailors that used those maps to chart their course. However there were also that chosen few who would dare to use the map to go right to that location, the place where the dragons were, just to see what existed there. The world is full of both types of people, those who can play it safe and are ok with that and those who would rather take a leap of faith and see what can be discovered.

Fear is a natural reaction to the unknown. You know the butterflies in your gut when you do something a little outlandish or outside the norm? Human kind likes to stick to things they know or have experienced already by their very nature. People VERY much enjoy their routines. There are however a few outlying individuals who like to challenge, who like to push the envelope. A group of people that sit on the up and down slopes of the bell curve, ever dragging it in one direction or the other. A group of people who are naturally more nervous about taking chances and on the other side a group of people not as nervous about such things. Corporate world or outside world doesn't much matter in this case - routine is king for some and not for others.

A fair number of people in the world note that programming as a profession has not been around all that long. Hell computers have only really been around for ~50 or so years, a great deal shorter then some of the greatest life changing inventions in history - life altering stuff such as the wheel, the light bulb or even your avg. telephone. So it should stand to reason that a large number of things pertaining to programming have not yet been figured out. There are plenty of examples of where this bleeding edge work is being done. Arguments about static typing or dynamic. Conversations about threading models - and whether or not it is the next big frontier. Blog postings about languages (yes the many and varied) such as Python, lisp, java, ruby, haskell, OCaml, smalltalk and many more. A great many places for programmers that contain the label "Here there be Dragons."

Now alot of people look in on those conversations and ask themselves if those conversations really matter to them. A great number of people are comfortable with what they do and where they are in the programming realm so what does it matter. Those same people asking are the people who would rather fall into their routine. The people on the other side having those difficult conversations are the people who managed to get the butterflies in their stomachs to "Fly in formation" and overcome their fear of the unknown to attempt to make things better for everyone.

So in the end - maybe you are comfortable avoiding places where Dragons lurk. I for one am not - and will constantly look for where the Dragons are in an attempt to bring a new eye to those conversations. I will look for ways to help clear the Dragons out for others and for myself. I will constantly strive to get my butterflies to fly in formation so that I can make the most of my life both personally and professionally.

Communication - A key to "Coding well?"

noreply@blogger.com (Joe Campbell) — Sat, 22 Dec 2007 21:02:00 +0000

There once again seems to be a little wave of interesting posts on a new topic. Steve Yegge had a post on what happens when code gets to big. Then my friend Raganwald picked that up and started to dissect the idea. Steve commented that the goal of most coders should be to keep things small (gross paraphrasing from a much longer post), make the overall code base smaller so that it is more manageable and more maintainable. Raganwald takes that idea and makes it painfully obvious why that somewhat simple directive doesn't make full sense without some understanding of what it means to make the code base smaller - stating:

"These are my thoughts about the relationship between program size and readability. It’s my take on how you can look at one short program and dismiss it as Golf, and look at another and praise it as being succinct and expressive."

Raganwald points out that code size is certainly a factor in how manageable a particular code base is, but that a certain amount of code bloat is both inevitable and needed in some cases (my interpretation on the post). You see what I think he is attempting to point out is that its not all about the size but what the size is communicating, and what things went into getting the code base to a given point.

Programmers are people

We all have ways of talking to one another and we speak a similar language here in the USA but not all of us understand one another. There are some local inflections and dialects that can make modern English hard to understand just as if people were speaking two different languages. The same is true of coding even if you happen to be coding using the exact same tool or language. Even if all the programmers involved in a given code base are each coding well it can still be hard for them to understand one another's code. In the end we are all working in a community of programmers (unless we are self employed or working for the man) and we have to understand each other, but is the code enough to garner this understanding between programmers in this case? In my opinion if you were asking Steve Yegge he might say it should be... and Raganwald would likely answer probably not.

Dialects - what is a standard to you may be silly to someone else

So to throw a nail into this idea that even in one programming language you can have different dialects or ways of doing work Max Kanat-Alexander says the following about the Bugzilla code base:

* There are many ways to do the same thing in Perl. It's even the motto: "There's More Than One Way To Do It." However, this means that each reviewer must enforce very strict code guidelines on each coder, or must learn each coder's coding style. In the interest of consistency, we usually pick the former. This takes more reviewer time. It's also frustrating for contributors who are used to writing in a particular fashion.

* More ways to write the same thing means there are many more bad ways to write code in Perl than there are in other languages. In any language it's possible to do stupid things and not realize it. In Perl it's easy. Or even when the code does what you mean it to, just because it works doesn't mean it's good. My experience is that Perl encourages people to write code that "just works," but might not be architected appropriately. Once again, this is possible in any language, but I think Perl makes it easier than other languages to write bad code.

* It's very easy to make Perl code hard to read. It uses strange variables like $_. It relies heavily on complex regular expressions. I don't think anybody would argue that Perl encourages readability.

Raganwald, using design patters as a way to illustrate, makes much the same point. Design patterns are one more way in which programmers can attempt to communicate to other programmers their intention without having to sit next to them and explain it verbatim. Gecko on programming.reddit.com (shamelessly copied from Raganwald, because I don't yet frequent reddit) makes a similar point as an assignment anecdote to his life as a college TA.

So Whats the point

The point is that coding small is good provided that people will understand the smaller code. Code bloat is fine for the same reason but might hurt maintainability which is a different measure, and one should always know how they are being measured. Making code smaller for the sake of being smaller is not a good way of looking at it in my mind. Making the code base smaller when everyone understands how you are making it smaller is a different story.

No matter what you have to make sure that, at the very least, the programmers you are working with are speaking with a common dialect. In my mind not having a common dialect is what leads to a large code base and one that is unmaintainable - and is a problem in the end that can not be solved by simply making the code smaller and more concise as Steve suggests. The problem is also not one that can be solved by introducing Design Patterns although it can certainly help you to get to maintainable code base by virtue of having people understanding what you are saying because they understand your dialect. The problem is unfortunately a people problem and is still unsolved in programming, "how do I make people understand what my code is doing above and beyond what the code 'says' - because it doesn't align with my personal dialect?"

(as an aside I think that the last sentence is what leads to that programmer syndrome that makes all programmers think that another programmers code is pure unadulterated poo.)

What ENABLES you - is IT on your side

noreply@blogger.com (Joe Campbell) — Fri, 14 Dec 2007 02:21:00 +0000

So the past few of my posts has been on development going faster due to help from the management perspective. Things like management removing impediments and not feeling high on themselves but instead taking the opinion and perception of the people they are helping as an indicator of the success or failure of their efforts. While I was writing that, my friend raganwald has asked us to stop blaming management. Now while I agree with that statement on the surface it goes a little deeper then I think his article implies.

So for a very long time programmers at the low to mid level have blamed architects and management for their problems. In some cases they even blame the business for their issues. What I have said in the past is that in order to address this blame game you first perceive that management is helping them. Step 2 is to make sure that you have your house in order. Step 3 is that the people running the environment you work in have to 'want' to help as well. Hence the remaining bulk of this post.

IT departments (from the top down) are more often then not run in a "command and control" fashion. What this means is that IT departments are often attempting to find ways to restrict what users can do, keep them from shooting themselves in the foot, make things as homogenious as possible in the name of making sure that they can support anyone and everyone in the company. THIS command and control idea is a fallacy and here is why I think so.

I believe very strongly that IT departments should be about enabling users to get things done. I believe that they should be more then willing to provide solutions that fit their needs, and when presented with something that doesn't fit the mold they have laid out precisely still be willing to accept things that make their end users go faster and get more work done. I believe they should be TECHNOLOGY ENABLERS not disablers, controllers, commanders.

Now what I am NOT saying is that IT should just willy nilly allow anything suggested, but rather they should work with people asking for 'different' things then what is currently being offered to understand what the need is and then move to fill that need. I mean that they [IT] should pro actively add features and functionality to provide users with choices. The down fall of NOT being this flexible is that users will want to work around the controls placed upon them. Human nature is to try and break free and do things perceived to be needed. The stronger the grip the more people rebel against it and the more things will slip through the grip.

So - which way does your IT department think? Are they enablers for their users, or are they command and control? I strongly think they should be the enablers - if for no other reason then not having to fire people working around their command and control systems.

OMG Moment in the car on the way home

noreply@blogger.com (Joe Campbell) — Wed, 12 Dec 2007 23:38:00 +0000

So at Big Co. we have been looking at ways to change how management thinks and innovate how management works. To come up with new and interesting ways to make the work place awesome for the work force, to prevent turn over. In essence to make Big Co. such a cool and wonderful place to work that people want to flock to it rather then flee in terror.

To the point above some effort has been given to attempting to bring some problems to light. A series of presentations on management style, problem resolution, introduction of agile across the Big Co. enterprise has met with some interesting commentary more then once. The commentary has been about bruising the egos of the management with the things that are being said in the presentations. For example, a presentation might say something like "Management focus: Remove impediments" the response to this was something along the lines of "...you might want to reword that because people [management] probably feels that this is what they are already doing."

So here is where the AH-HA came in for me and why I felt this nagging bit in my head that the statement provided as evidence for 'dulling' that management focus statement to avoid calling someones baby ugly was a bad thing.

When we start our jobs in the Big Co. world we are all provided with instruction in sexual harassment. In this little bit of learning we are told that it is not the intent of the person doing the harassment that matters, it is how it is perceived by the person being harassed. So something that I might think is perfectly innocent someone else finds offensive and as such 'MAY' claim harassment. Having to reword the statement made above to avoid bruising egos strikes me the same way.

If the people that work for you are telling you that they do not feel that you are working to remove impediments to them doing their job there is no reason for you to be personally offended. In this case it is the workers perception of what you are doing as a manager that should be taken as gospel. It is the perception of management not doing something that made someone put a particular statement onto a presentation. Now sure you can say that you should be more political about it maybe... but reword it just because management already feels that are doing it? HELL NO, it is not managements perception of that statement that matters, it is the perception of the people making it that does.

Put another way, if you were the manager, imagine how in the dark you might be if you NEVER talked to the people you were managing. Those people working for you have insight and information. Those folk may be under informed of all that management is doing to help them - but if that is the case then the perception of not doing a thing is easily removed with greater transparency and communication. Tell things like they are and help management to understand that it is not about what they think they are doing it is about what people perceive that they are doing that counts.

Crazy is as Crazy Does - Joy in the job

noreply@blogger.com (Joe Campbell) — Fri, 07 Dec 2007 17:59:00 +0000

You're a programmer, do you find joy in what you do or have you become Numb due to your employers "...wilful ignorance of software development principles..."? I think that Johnathan Dodds hit it on the head when he said

"I haven’t gone numb. I have passion and a sense of professionalism that’s independent of any company’s performance review.

Someone once told me that every workplace is crazy; the trick is to find a place that matches your kind of crazy."

So ask yourself, are you working for a company that is ok with your type of crazy? Better yet does your company SUPPORT your type of crazy such that it is not passed off or passed by but given the creedance that both you and the company feel is appropriate?

If not, why are you still working for them - start looking for a better fit - don't go numb, step up and step out and be both happy and proud of the things that you do. Find the job that fits your type of crazy, one in which you can let your hair down far enough that the company knows who you are and you understand the company. Don't let the work a day world turn you into a dull, numb, mindless programmer. Be passionate, be crazy - Suggest the outlandish and have the desire to follow it through to implementation. BE PASSIONATE about programming if it is your job. You should expect to be nothing less.

Taking time out - the pause that innovates

noreply@blogger.com (Joe Campbell) — Sun, 25 Nov 2007 19:56:00 +0000

So, in my current position I have been giving a great deal of thought to what I can do to help people be more productive in their programming jobs. I have been working with some wonderful people to both improve myself and to help Big Co. grow and become better at what it does in the world. One of the topics of discussion that has come up recently has been stirring in the back of my head. The discussion was around finding ways to innovate in the management realm to support doing "the work of Big Co." in new and innovative ways, ways that can not easily be copied by other companies because they are internal processes to Big Co.

One of the specific subtopics during this discussion was around providing time for people to innovate, time to pause and stand back, time to contemplate what it is they are attempting to accomplish or what it is they have been asked to do. I am writing about it now because as coincidence would have it this simple idea, the idea of providing people time to 'think on things', came up during a sermon I was listening to.

Now the sermon was about the Sabbath - the day of rest. What was said was that the world is moving fast. We all feel that things are faster then we would like - we even gage each other on how busy we are, almost as if it was a badge of courage, or something to keep up with like a busy/activity based keeping up with the Jones. This same feeling of quickness occurs both at home and at work. The work a day world at Big Co. is fast paced. There is a constant focus to get things done and get things done faster (translate that into getting more things done in a given time box). Put simply management at Big Co. wants their people to add value to what is going on in a faster manner. However for people in Big Co. to add value, I would argue that there needs to be built in time to rest, time to innovate, time to simply sit and think about what has been presented to you as the "THING that needs to get done." There is, however, a consistent lack of time built into the Big Co. schedule to 'contemplate', no time to pause and innovate. In short there is no Sabbath.

The draw back to this management focus on getting things done faster is that there is a myopic focus on the short term. The benefits right now are the focus. What this can leave out is future based planning. The other thing it can leave out are the "AH HA" moments that can result out of taking a moment to think about what is being done or asked for. Stepping back to see a larger picture can help Big Co. to plan better, it can help Big Co. employees to come up with innovative ways to solve problems presented such that they solve other well known corporate problems as well. As an employee you can better see connections between things. You may even have the time to have an epiphany that leads to Big Co. changing its direction and saving hundreds of thousands of dollars to the bottom line. Adding a pause between getting things done may simply prevent Big Co. employees from jumping ship to another company - but one could argue that just in preventing turn over you are saving the company money.

So the question is do you take time out to contemplate and think on things? Does your management provide you time to sit and think? If the answer is no please consider that taking time out for individuals might be necessary for Big Co. to grow to a new level, to expand into a new place. It may be specifically needed for individuals to grow and innovate as well. Stressed people think poorly, well rested individuals that are relaxed in what they do that have time to think clearly are setup to innovate. So are you set up to innovate or are you set up to be stressed the answer may surprise you.

Go Fast Myopia - Is your house in order

noreply@blogger.com (Joe Campbell) — Tue, 13 Nov 2007 18:26:00 +0000

So my previous post was on getting the fundamentals correct. Why even bother writing a post such as that, especially about items that should be so self obvious to most programmers? Here is my rational. While we all know what the Fundamentals are we are not all working on them in our jobs. In fact in a number of cases we are ignoring the fundamentals all together letting Big Co. mandates and dictates impinge upon what we should be doing. Beyond that Big Co. may actually be dumbing down programmers in large numbers turning them away from the fundamentals because Big Co. may not know what the fundamentals are.

You see Big Co. focus is on getting more done. This focus is about getting more done in a variety of ways. Big Co. may be looking to get more projects done, they may be looking to get more features or more function, for the most part their desire is to see the company address business needs faster and more accurately. The problem is that this want by Big Co. to get more done seems to breed a certain type of myopia that is hard to get rid off. More importantly unless you have a special breed of programmer this myopia is contagious and can be deadly to the programmer organization.

So programmers are looking at the current code state and saying it is hindering efforts but it does not seem as if anyone is doing anything about it. Big Co. brass is saying you have to get twice as much feature function accomplished this year in comparison to last years numbers. They are saying you should go faster, so you try going faster, cutting corners, ignoring the fundamentals. You stop doing unit testing, you focus on getting to the end result. You accomplish your task faster, but now your code sucks and it takes forever for it to make it correctly through QA. You have not saved any time. Big Co. brass (CIO, Manager) takes all of this to mean that her team is moving as fast as they can already. Programmers may or may not feel this way but such is the Big Co. reality. They are slowly becoming more myopic and turning a blind eye because they don't know any better.

This myopia starts to make them look at ways to improve speed by adding people. Now I think we all know that this doesn't work, ESPECIALLY when you don't have your own house in order. If you don't have a good working code shop in place already how can you expect to get quality from an outsider? What outsiders will see is that they get to code in the exact same way that people in the company are. The result will be just as shoddy as everything else. No fundamentals, everything is a mess.

So how to you solve this myopic view that your people are currently at their maximum throughput. Put the fundamentals in place and enforce them. Give people the want and the need to do the fundamentals. Give them the time, help them to remove impediments, help them to understand that if they take time to help the overall situation they will be helping every one else to move faster. They will be removing the impediments to moving fast in the code. When this starts to happen it will help to have management removing impediments as well. They can help by pushing on the business long enough to solve the biggest problems. They can help to rearrange people in the organization to remove people issues, resourcing and a variety of other things. Big Co's myopic view that we are at our max starts to change and they see they are not moving as fast as they could. Big Co. brass starts to see that they can influence change in ways other then just adding more FTEs, which we all know doesn't work.

So whats the moral of the story? Since we know that adding people doesn't work (or at least doesn't help as much as one might expect) do you know that your own house is in order? Is Big Co's myopia bleeding into your job? If it is take time out to attempt to educate, work to get your house in order - SHOW everyone that the fundamentals can make things move much faster. Make sure Big Co. knows of their own blemishes and is working to solve them before they look to add more people or offshore, make sure your not myopically ignoring your own problems.

The (Fun)da - mentals : Are you getting what you pay for?

noreply@blogger.com (Joe Campbell) — Tue, 13 Nov 2007 18:24:00 +0000

Is your code or code base a mess? If you think it is do other people that you work with also think so? Do you constantly feel like you 'HAVE' to rewrite the code (more then a simple refactor)? If you answered yes to any of these questions I have one more for you that in part attempts to address the above questions: Do you practice what we all know are the fundamentals of programming regardless of the language you happen to use? Lets turn the rock over and see.

So you say that the speed with which new business code can be developed is slowing down. Maybe you are even saying that new implementations of business features are being hampered by the existing code base. Lets assume for the purpose of this post/discussion that you have been in your current position long enough to notice and potentially make comments about problems that you are spotting in the code base. Lets also assume that you are attempting to be constructive rather then just calling the offending code items pure tripe. When you speak of the offending code what are you saying? What I tend to say these days is that it doesn't meet the fundamentals very well. People often ask me what I am saying when I speak of fundamentals when looking at code. So here is what I explain.

You have to want to learn from past experience, by this I mean both the past experience in the company itself but also the past experience of developers that may have tread where you are now. Keep in mind that there is almost always someone that comes before you and they may have done something similar if not exactly like what you are doing now, at some time in the past. It does happen now and again that you get new novel problems to solve, but these are becoming more rare in corporate America and more the stuff of universities and start ups. So start by attempting to address what happened that lead to where the code is now.

Now you have some history - you can attempt to look at the specific areas in the code that are not done well, you can start to focus on the specific items that make you want to say "I need to rewrite this code" (beyond, of course, your personal distaste of the implementation). This is where the fundamentals come in.

So we all know what problems can exist in code but it might be interesting to see a refresher, so here it is. If you think / want to rewrite your code base and you have done your home work on this history then you can use the fundamentals to start bottom up and address the programmers actions that got you to where you are now.

Code smells - generally after working in a code base for a little while I bring this up as a topic to investigate. Code smells can lead to a code base that no one likes to work in. Teach your programming team to notice and raise these smells as concerns more constantly. Visibility makes these items hard to ignore and you can start to quantify what draw backs the code smells are providing to getting features implemented.

YAGNI - You're Not Gonna Need It. Lots of people ignore this one by way of attempting to be overly flexible in their implementation to attempt to accommodate a schizophrenic business that can not decide on what is the most important thing to do in the company. This is larger then the programming team, but is certainly one of the fundamentals that should be applied and paid some attention.

DRY - Don't Repeat Yourself. The urge to cut and paste working segments of code from one place to another is tempting. However when you find yourself taking the same block and copying it all over the codebase it starts to scream out that you should do something to provide that block as a common item rather then blindly copying the block all over the codebase. Both achieve usage, and both styles work, but when copying the block all over the place if the business logic in it changes rather then one spot you now have many to go fix. Taking more time then you need to to make what should be a simple change.

KISS - Keep it Simple Stupid. Along the lines of YAGNI this is a big fundamental item. Do not over complicate the problems you have, solve them. Solve them elegantly if you can and if not do just the minimum that solves the issue. Don't over do it, don't gold plate, and don't over complicate it. All that over complication will make things harder then it need be later in maintenance mode.

Fail Fast - In almost all cases you want your program to fail fast rather then waiting to bubble up and error at some point in the future. Future based errors or attempting to run when a part of the process is known broken can cause errors that occur much later, and disconnected from their initial cause. This makes for a nightmare debugging, root cause analysis problem. The error is not connected to its root and as such nearly impossible to find.

Refactor - Good god - this might be the most important of all the fundamentals. If you are not taking the time to notice problems and then make them visible and then ADDRESS them you might as well be ignoring a wart on your nose. Refactor always and do it within the confines of the other fundamentals and the risk tolerance of the place you work.

There are many more fundamentals and I would encourage the reader to do the diligence, go find the other fundamentals. Work them into how you do your work, attempt to work them into how your teams of programmers do their work. Use them as guidelines to development and you might be very happy with the result. You may find that over time the ship seems to steer itself and the codebase starts to look better and you don't feel like the code you work with is complete poo all the time. Let your bosses get what they paid for, a seasoned developer that will work to both improve the code, the people they work with and the processes of the company.