Boosting Your Chess Skills - Recently I have read a few articles on how to quickly boost your chess ability. Hey I am always down for a shortcut. Well you can't get something for not...
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.
One of the mid-level managers on my project wanted me to show a new guy what I was doing on a big bug fix. So every morning I would call him up and check up on him. I would give him tasks to do. Then I would check back on him at the end of the day. My first assignment was for him to replicate the problem I was fixing.
You would think that this was an easy task. I did all the heavy lifting, mining the audits, and discovering the root case of the problem. I came up with an ironclad set of steps to recreate the problem. I turned the new guy loose on thse steps. And then ... he got nowhere.
New guy did not have a database schema. What? How the heck was he doing any work. I told him to call the lead DBA and get them to setup a schema. Next he did not have any database tools. So he got a copy of SQL Developer installed and configured. Then he did not have a working version of our application.
Wow. This is tough work. But it is all good. If it was too easy to step in and get settled with our system, they could hire any lackeys to do the job at a cheap price. Today the developer said the IDE was complaining that a C source file was missing. I had him check whether the Pro*C file was generating the C file. Nope.
There was a mismatch between his Pro*C code calls and the stored procedures in his database. Showed him how to get the source code of the stored procedures. He then compiled in the latest stored procs and still had the errors. Turns out he was using the wrong Clearcase view to obtain the Pro*C code. Killer. This guy is going to need to go a long way just to keep up, let alone add any value.
I had finished a big effort in development. Checked my code into the main branch we were working from. There were two separate branches that were making changes for another version of Windows. Then I found out that I needed to deploy my changes to Windows. You would think I could just move my code changes to the other branch. Not so fast.
In the past, I would manually do the merges. That is just painful, especially when my target is two other branches. This time around I decided to use the help of the Clearcase tool. I think it is called the Merge Manager. You choose your version, click on Merge, then click the target of the merge.
Things worked fine when the merge was simple. Sometimes I could not figure out how to select the correct destination. I just reverted back to manually promotion of the code. The real trouble came when the merge was complex. Me and other people made changes to the same places in the same files. Sometimes I could use Merge Manager to sort though the mess. Other times I had to go back to manual merging.
The bottom line is that for simple cases, Merge Manager helped me merge a lot of files much quicker. Yippee.
Just read a blog post from a young developer working on the Microsoft Azure team. He is finding that corporate development is nothing like writing code for his personal products. Good thing he learned this lesson early in his career. Some people spend a lot of time raging against the machine before they figure out how things are done in the corporation.
One realization was that there is no good documentation. Yep. It is hard to write things down in a readable manner. Who has the time for that? You need to ship products. Plus hackers say that the source code is the documentation. Amen to that brother. Another thing this young buck found was that code quality is not job 1. Yep. There are many times when you need to cut corners to get things done. And you never come back and fix things up later. This is probably a big reason why a lot of software sucks.