Edgy Rebranding - I just read that 37Signals is changing their name to Basecamp. That seemed odd initially. I know them by 37Signals. Why give up all that brand juice? Sure...
Some performance problem popped up in our production environment. A bunch of us developers got together and sketched out possible solutions. We brought in some DBAs and came up with an optimal approach. After this initial huddle, a manager and developer went off to research the solution further.
This weekend I got the notice that I needed to implement the solution ASAP. Then I was asked for an estimate on how long it would take to knock this out. I used my trusty estimator spreadsheet. I have found it to work pretty well. Since we already designed a solution, I cut out the design hours.
On day one, I tried to manually check out the solution. Oooops. The SQL would not compile. I spent a day struggling with it. I called in a bunch of managers, developers, and DBAs. At first nobody else could get the design to work. Eventually a DBA and developer came up with a related desgn that would work. Problem was that now I was a day behind schedule.
I am working on a new change for our system. This has been a rush job. All jobs are rush. But this one is really a rush. I started to think we were in trouble when a requirements analyst asked me for questions, then was unable to answer them. You can’t meet rushed schedules if you don’t know what you are doing. I decided to just go with some assumptions and run with them.
I knocked out a design document for my changes. This document assumed you already knew how the existing system worked. It also assumed that you knew what the new changes were about. My goal was to make sure a coder could read the design and immediately implement the thing.
A day before the customer was supposed to receive my design document, I passed it to some managers for review. One of the managers was new. He did not know what I was talking about in my design. Well yes, it was written for system experts. I did take the comments and reformatted my design. I wrote it from the viewpoint of a newbie.
Luckily I left the pseudo code section the same. That is the most important section. I got PL/SQL code in there that is pretty close to ready to compile. Now that does not mean you have to cut and paste my code verbatim. But if you know PL/SQL syntax, you will know exactly what you need to code.
I have to roll out a new feature for our customer's system really soon. Since everything is rushed on this job, the requirements analysis team needed to step it into high gear. I was required to attend a few meetings. In the kickoff meeting, some ideas were thrown around. Then the floor was open to questions. I asked some details about the main flow of the feature. The result was that I was asked to go research the answers for the details. WTF?
After getting assigned some action items based on my questions, I clammed up. I am the developer on the project. I write, test, and roll out the code. Requirements analysis is not my responsibility. I don't have the time to take on a second job on the project. Somehow the requirements phase is being run in a backwards way.
Since I have to actually produce the features, I will need some requirements analysis done. However I can do that on my own when I am rocking and rolling on the design phase. There is no reason for me to do all the work, but have to slow down for some requirements analysts to just try to get me to do all the work for them. Not good.
I have been working on designing a solution to the latest batch of requirements to our system. There was some error on the scheduling of this task. Somebody put a placeholder in the schedule, estimating about how long prior jobs like this took. That is good for a placeholder. That will not work for the real schedule, especially when the customer wants a whole lot more than usual this time around.
I brought up the issue a couple times. Finally someone took note and realized the schedule was all screwed up. The managers got together and put two senior developers on the task. The problem is that one of those senior developers works more like a junior development.
The project manager asked me if we could pull this off. I told him yes if there were no other interruptions. Another manager said we needed to fix a few bugs. I said we could fix some bugs, but all that needed to be factored into the scheduel. A final schedule was drawn up. Then we got down to work.
Along comes a requirements analyst. She told me the customer wanted to make a change to the requirements. I Said that was fine and could be captured. But we could not act upon those changes with the current schedule. The analyst told me the customer would not be happy with this. I replied that happy or not, the scheduled could not accomodate changes to requirements. This holds true even if somebody thinks the changes are small.
In the end, I got management backing. The new changes will be addressed in a future delivery. The moral of the story is simple. Figure out all the requirements up front and then freeze them. If you do not do that, there is no way to keep a constrained schedule, especially if it is tight.
I am taking a PHP development class at college this semester. So I thought I would browse around to see what qualification you need to get a PHP Development job. Of course you need to know the PHP programming language. It appears you also need to know some associated technologies like Drupal.
PHP is the fourth component to the LAMP stack. I guess you better know the other components as well. Seems like there is a whole host of technologies you must learn to be a web developer.
Some of the PHP jobs I found paid a nice wage. Others were weak. I liked that I saw PHP posistions that require things like Python and/or ActionScript. I plan to take classes on those languages soon. Here is the whole list of technologies I found PHP developers should have:
- cross-site scripting
I just read a post by Benjamin Podgursky on the relationship between programming language and income. Very interesting. PHP was near the bottom of the list (least paid). That was disappointing. I am trying to learn PHP this upcoming semester. Then again, the rationale behind the low salaries was that PHP is easy to learn. I will be the judge of that. But I am optomistic.
Near the top of the list was Java. Yeah. I am brushing up on my Java right now. My manager told me I should probably be learning J2EE better in the next year or two. I concur. Something surprising at the top of the list was ActionScript. I thought Flash was on the way out. Perhaps its demise was overstated.
We had an old trouble ticket that we wanted to resolve in the next maintenance release. One of the developers got assigned to determine the root cause of the problem. Everyone was hoping the analysis would take around a day to complete. After a week of analysis, this developer made no progress. This was going to cause us to slip our release. Not acceptable.
The analysis got reassigned to me. I was told I had a day to complete the analysis. There was already a work around in place. A script ran hourly on the cron that tried to detect and correct bad records. I traced down one of these corrections in detail.
I was frustrated because I could not figure out how the records were wrong. In fact, I kicked it into high gear and proved that the records were not wrong. That’s when I made a breakthrough. The workaround itself was buggy. It was rooted in a timing issue. Not a rookie mistake.
Once I knew that I could not trust the work around, I found a real example of the bug. Then I reconstructed what happened to cause the problem. It was tricky too. There was an optimization in one of the database triggers that tried to skip some unnecessary updates. However one of those updates was masking crucial changes from another update. Doh.