Last Minute Changes

Today there was a meeting scheduled with the customer to review some last minute requirement changes. I went to lunch early so I would not miss the meeting. I dial in to the conference, but all I get is elevator music. After a while, the requirements team calls me up. I find out that I dialed the wrong number. This was a bad omen.

We get into the meeting. The requirements team drives the discussion. But they always go to me for all customer questions. This time around I had them document exactly what the code does. The danger is that this opens up all kinds of discussion. Now is not the time to discuss. We are at the end of testing. However it is better to get the bad news now than later after the code is running in production.

I get banged up a bit. There are some surprise requirements. I take it in stride. Right after the meeting I am banging out code. Luckily I have a huge unit test code library that helps me test out the changes. But guess what? I found a bug in my unit test data generation routine that is affecting the latest changes. I debug that and then test out all the new stuff. Oh boy this is so last minute. Luckily I am going on vacation next week. People on the team are scrambling to figure out who will be backing me up next week. Rant off.

LOL

I had a ton of messages on my phone when I got in this morning. Nice. One of them was from my team lead. He usually does not call me. So I got in tough with him right away.

A project manager had asked him to get me to check up on a customer problem in the production environment. Apparently he thought this would take me all of 10 minutes. It actually took longer than 10 minutes for me to even understand what the heck they were asking.

Here is what I gathered. The customer testing group had some concerns over some processing. Our manager wanted me to mine the production data, figure out from the data whether the customer concerns were valid, and provide the hard evidence either way.

All I can say is LOL. If I were given a few days, I could knock out this work. But 10 minutes? Please. Each of the many queries I need to run against our huge production data set might take 10 minutes. Right now I don't even know how to compose the queries without doing analysis up front. My team lead is a true diplomat. He said that he would respond by saying that my hands are full, and that I would try to help if I got any free time.

Muhahaha. You got to love my team lead. He is a politician in the making. I actually work directly for a different manager. He directed my to spend my time working on some new customer requirements that need to go out ASAP. I was told that I can direct all my time on that task. I am going to follow my direct manager's orders for now. Still laughing at the 10 minute estimate though.

Small Changes Take Long Time

Some testers discovered some differences between our written requirements and they way our software was working. We decided to change the requirements to match the software. This really was a documentation problem. You would think this would be the end of the issue. No chance.

The customer inspected the requirements. They realized some other things were missing as well. Those other things were not in the software. Essentially the customer wanted some more last minute changes. They said this was important. Oh oh.

Now of course these changes were to be done by me. I was asked how long the changes would take. I conservatively estimated a few days minimum. My boss translated that into a 32 to 40 hour job. Why does such a small change take so long? There are many reasons. We got to make sure we get the requirements right. That job should go to an analyst. However you know a developer needs to be involved.

Then you need to code the change. That does not take much time at all. Next you need to do your testing. It is difficult to set up just the right set of unit test data. You also need to document all your tests. Guess what else needs to be documented? Changes to the design. This goes in the design document. Then we need to roll out the change to all the environments that need it. There is internal test, customer test, then production. Now 40 hours does not sound all that long.

Easy as SendMail

We have a data correction script scheduled to go out to Production. The results are supposed to be emailed to the customer. A DBA got assigned to help with getting the email produced automatically.

Being a developer, I thought it would be as easy as getting an API from the DBA on how to make the call to send an email. Nope. The DBA wanted to take the script and implement it himself. Bad sign #1.

My boss wanted me to ensure the email was being scheduled at the right time. Turns out the DBA was confused over when to do the work. Great. Then it turns out that the DBA did not know how to actually send the mail.

Another DBA asked if we had SendMail capability on the UNIX box. How do you test this? Easy. Run /user/lib/sendmail, passing an email address on the command line. Then enter in some text for the body of the email. Finally type a period followed by the Enter key.

Email will either be sent or not. For the record, it works on my UNIX development box.

Dreamspark to the Rescue

I own a personal copy of Microsoft Visual Studio 6. It was purchased with my own money. When I first arrived at my company, they handed me a laptop. I was told I would get an additional laptop to do the development for our customer. It would just be a big wait.

What did I do? I installed my own personal copy of Visual Studio 6 on my company laptop. The main reason I did this was that I use Visual Studio as my text editor. I am very familiar with it.

Just the other day, Visual Studio 6 started aborting on my when I tried to open a file. The problem happened again today. My solution is to unintall and reinstall the darn thing. However after uninstalling, I looked around to see if I could install an upgrade instead. I have not purchased a new copy of Visual Studio yet.

Luckily I am a student in the local community college. Through Microsoft's Dreamspark program, they provide free access to all the professional versions of Visual Studio. Why should I not go to the most recent Visual Studio 2010 install. The install is 2G large. I hope it will be worth the wait. Thanks Microsoft.

Dreaded Screen Shots

I am on loan to my old team to take care of some high priority problems for them. At first I protested. But the boss said they needed help. So I am finishing up the development of a fix. Then I needed to help the quality assurance team test out my changes. Fair enough.

Now I got some bad news. The quality assurance team is too busy to do any testing. So I got to do the testing. That by itself is fine by me. I unit test my stuff. I even produce a unit test plan complete with the results from testing.

However I got word that the tests required a big document that showed exactly what was tested and how. That means there needs to be a massive Microsoft Word document with all kinds of screen shots. What? Come on now. Don't make me join the insanity. I am all for doing tasks that add value. But this seems ridiculous. Nobody is going to be looking at this massive document.

Perhaps I should just paste in some random pictures and forget about fighting the system. What do you think?

All About Timing

I am working on a high priority problem our customer has. They told me the behavior of the applications is unacceptable. No problem. I am the Maintenance Man after all. So I coded up the app changes that will takes care of their problems. You would think that I am done. No chance. There is much more to it than that.

Next I ran through all my unit testing. Then I need to get my changes over to our quality assurance team. You would think we could just click a button and I could get them a build. It is never quite that simple. There are all kinds of manual processes to get a build to test. Now I need to go through them.

The end goal is to provide the fix to the customers. However the powers that be in the customer organization want to limit any changes we send them. Therefore I need to clear my release with the big dogs. Next I find out that it takes 72 hours for the customer organization to receive my app and install it everywhere. Luckily I know all these things. All this overhead is baked into my delivery estimates. And you wonder why it takes a few weeks to push out 20 lines of code changes. Now you know.

Going to Sleep

I got the fun assignment of implementing some object locking mechanisms. That is some good stuff. Me and another developer debated the design. When we were done, I was off to the races to code.

Now the general idea was to check whether there were other locks, and if so, wait a while before checking again. A little while made me think of sleeping and giving up my thread until a certain duration had passed.

My instinct told me to call the sleep() function, passing it the number of milliseconds I wanted to wait. The compiler did not recognize sleep(). Okay. I just need to find the correct header file to include. Was is ? No. that one is only valid for UNIX. I am on Windows XP. Then I figured out the error of my ways. I already included . However that header file has you call Sleep() instead. Notice the capital S.

Now I am unit test the basics of my implementation. My virtual machine is super slow. Perhaps it is time to call it a day (and a week).

Angry Customers

My boss told me to go help out my old team. They were down on resources but were getting a lot of work. These guys were overworked. I protested a bit because I am busy with my new team. However the manager makes the final resource allocation decisions around here.

I wanted to take care of one of their problems that relates to my new team. My manager threw me on a high priority problem their customers were having. I gathered some logs and screen shots. Then I found some problems in the code immediately. My manager set up a conference call with a lot of the customers.

On the call I presented my findings. Then I walked the customer through some of the causes in their production environment. I heard a few things loud and clear in our conversation. The customer repeatedly said that the application behavior was unacceptable. Luckily my manager had prepped me with the info that these customers were livid. I tried to keep my cool. Then I presented some options on how we could fix their problems. Their answer was to just fix the damn thing, and let them know when it was done. Damn.

Developers Locked Up

I got a call from some developers on my old team. The customer was having a problem with the applications. The devs traced it back to some home grown locking code. They were confused about some Pro*C code that executed what looked to be an EXEC SQL AT followed by a table name.

Luckily I had traced through this very code about a year and a half ago. In fact, I blogged about it on my Oracle Development Blog. We did not need to consult my blog. I remembered enough about it to explain it to the boys.

This is a construct in Pro*C to execute a SQL statement under a different database connection (session). One usage of this is to do some SQL and commit the changes without affecting any of the ongoing SQL in your current session. That might be needed for some logging, or in the case of my old dev team, if you want to do your own locking.

Previously I had thought that the lack of such knowledge could be fixed by some training. But one of the devs on my old team had gone through Pro*C study and training. When I explained what the SQL did, he seemed to recall a bit of it. I guess training might help you out sometimes. However there is nothing more valuable than hands-on experience.

Unit Test to the Rescue

I inherited a subsystem to maintain. Made some changes for the next major release. This code is a pain to test. You have to have very specific data to excite all the cases. At first I was manually updating data using SQL commands. However I found it way too tedious.

Luckily I decided to put a bunch of code into a database package that generates test data at will. I spent a lot of time creating that test data generation code. Then I had to debug the test generation code. However now I am benefiting big time.

I had to do a last minute move of some setup data from one script to another. Then I was able to generate unit test data with one call to a stored procedure. Check. Later I removed a bunch of debug code from the main database package. Does the code still work? I used the test generation code to set up some more test data in about a minute. We are good. Now before moving on to the next job, I am going to make this unit test generation program even more flexible. Good stuff.

End of the Pattern Club

I remember a new application our team needed to implement a long time ago. There was a young group of developers eager to do well. They were also led by a young guy. These dudes had a number of ideas about how to solve the problems for the customer. One of their main techniques was the use of design patterns.

Now I am all for using a pattern when the situation calls for it. However these guys were pattern crazy. Everything was going to be implemented as part of a pattern, whether it fit or not. They had a tough time coming up with the need for the singleton pattern. They ended up trying to force it in two places in the application. What a sorry state.

Recently I heard that patterns have become vogue. This is because they have essentially been a failure. Developers really don't know patterns well. Sure they can name a few. But they cannot spot the right place to use one of the many patterns out there. This is a generalization. However I think it holds true. The only reason to know patterns now is to pass an interview where they ask you about some pattern basics.

Tough Job Market

Saying the current job market is tough would be an understatement. People stay unemployed for a long time when they lose their jobs. That makes them desperate for anything. We interviewed a dude that had a lot of experience in the specifics we were looking for. The guy seemed like somebody I wanted on my team. I told my boss point blank that we needed to hire this guy.

Turns out the poor dude was looking for work during the last nine months. How can a guy like that stay unemployed for so long. We got lucky and hired him before anybody else realized that this man would be a producer. In fact I think we did not pay him the going rate. I am concerned that if the economy improves, somebody else will steal him away. Now my recommendation to my boss is to give him the big bump up in compensation during his next review.

This story is not uncommon. I have heard that people with great skills and outstanding resumes are having trouble finding jobs. It does not seem to help even if people provide you with great references. I guess the old school method of getting jobs will work best. Get in contact with the people you know. Have them help you out. It is rough out there. You need every edge you can get. And if you have a job right now, hang on to it. I know I am.

Had a Bad Day

I was reading this software trade rag. There were a lot of ads in the magazine. I guess that's how they give me the thing for free. One ad in particular stood out. It was irreverent. It was fun. The thing had me hooked. So I went to the company's web site. I read a few blogs on there. Left some comments.

A few days later I got an email from a blogger that works for the company. He offered me some free copies of some software from the site. Here was their proposition. They make it easy to produce reports using their add-in to Microsoft Word. Now we got some complicated reports that took a lot of programming on our project. However the blogger asked me to give their products a try and let him know what troubles I had.

I had some troubles figuring out their product lineup. There were some reporting engines. And there was the add in. Should I install them all? Tried to go read up some docs on the company web site. Trouble is the links on the site did not work. Damn. Well I decided to install the Word add-in and see how it worked. Setting up a database source was not intuitive at all. I struggled through it and got it to work.

After running the template provided with the install, I got the Word document to pull in some data. It was not the data I wanted to see. So I logged into the database, made some updates, and committed the changes. Then I ran the report again. However it did not show the new data. Ooops. I reported back my troubles to the blogger. This piece of software sounded interesting. But it was too much trouble for me. We probably don't need the thing on our project anyway.

ORACLE_HOME

I am unit testing a bunch of scripts that normally run off the UNIX cron. Luckily they output their status to a log file. However the log keeps saying I have an SP2-0750 error. The text of this error is "You may need to set ORACLE_HOME to your Oracle Software directory."

Well I set my ORACLE_HOME. I can run SQL*Plus fine from the command line. Then I thought maybe the process I am spawning to run the scripts is not inheriting my environment variables. Nope. That can't be right.

Finally I try running the script in a different way. I make sure any changes the scripts make get reflected in my own parent environment. Wouldn't you know it? Somebody is resetting my ORACLE_HOME to an invalid directory. Further investigation shows that the scripts initially source a profile that has the wrong ORACLE_HOME.

I knew a little bit about what was going on. However all signs were pointing in the wrong direction. It took a high level of debugging skills, coupled with a lot of test time to figure this one out. I get the feeling that I am going to be having a great challenge testing out these scripts.

Archos 7 Home Tablet

Dont you hate that the cool iPad costs at least $500? I know I am. Luckily there is a cheaper alternative. The Archos 7 Home Tablet has a retail price of $199. In fact, you can get it for $189 from Amazon including shipping. That's the same price of an iPod Touch, not an iPad. Let's look at this economical device.

The Archos 7 has a 7 inch screen, is 5 millimeters thick, and weighs less than a pound. It has a kickstand to prop it up. There are no buttons on the thing. It has a resistive touch screen for user input. The thing is similar to the smaller Archos 5 Internet Tablet.

Inside the Archos 7 has 128MB of RAM and 2GB disk space. An 8GB model runs for $240 retail. The display has a 800 x 480 pixel resolution. Built in speakers are very powerful. It supports 80211b and 802.11g Wifi. The battery let's you watch video for 7 hours before needing a recharge.

Loaded on the Archos 7 is version 1.5 of the Android operating system. It is good that they have an open operating system. But the version is an old and outdated one. There are 5 apps preloaded on the system. You do not have access to all apps written to Android. But you can get apps from the AppsLib store which boasts about a thousand apps.

The Archos 7 comes from a French company. It supports many video formats, including High Definition ones. There is no Flash support, just like the iPad. It is good for reading eBooks. You've got to love the free Android apps that are out there waiting to be downloaded by you. I think I just may have to go out and get myself one.

Communication and Leadership

I was packing up my bag to get ready to leave work today. The guy who leads my old team dropped by and had some bad news. He said I needed to attend a long meeting later this week to work through some bugs with the customer. Then he said I needed to stick around today to help the team prepare for this meeting.

When asked to do some work that is not my official role on the project, I always start making calls. I immediately called up my manager. I reminded him that I moved to another team over a month ago. I also said that I had a schedule to keep with my new team. I asked why my schedule was getting loaded up with work from my old team.

I ended up conferencing a bunch of developer from my old team. I spent an hour walking developers through the problem resolution process. Now I do not normally care about incompetence. But I do care when it means I have to do somebody else's job. Don't try that mess with me.

Lack of Review

I have recently taken over the maintenance of a back end job. It communicates with another system. Most of the business is written in Oracle PL/SQL. There is also a mixture of Korn and Perl scripts involved. My first task was to implement a new change the customer wanted.

Luckily I inherited a pretty detailed design document. So I updated the thing with the new changes that the customer wanted. I asked my boss what I needed to do with the document. He said to give our internal team a day to review the thing. Then publish it and schedule a walk through with the customer.

Got no comment back from the internal review. Nobody read the thing I guess. My boss asked a few questions. That led to some changes. Then the document went out and I headed to my meeting to go over my design changes. The meeting was held at our customer's building. I knew a guy who worked at the building. He signed me in. I got dropped off in the room where the meeting was to be held. I practiced my intro a couple times so that it would be smooth. Also jotted down some notes on the sections I wanted to hit. Nobody was showing up at the meeting though. My boss said all types of big shots would be there. I guess my design passed. Wrong. More on this next time.

Dream Tools

Last night I read a rant about the state of development tools today. The guy had a good point. We got powerful hardware out there to run programs. Why can't we have powerful software development tools to make use of that hardware?

IDEs take a while to get your project started. Let's have an IDE that let's you start writing code immediately. Debuggers let you step through code with easy. How about we have debuggers that let you step backward in code execution, undoing the most recent operations?

Speaking of debuggers, let's get one that handles mutlithreaded apps with ease. Take it even further. Let's see if debuggers can trace through communication with other systems.

Finally here is a request that hits close to home. Recently we tried to build the first version of our next release. The thing was just not putting the files in the installation media. We have a manual process of inspecting the build output to ensure all went well. Why can't our build do that itself? It knows what's supposed to be in there. Let it automatically check what the heck actually went into the installable output.

Scrum Tips

I have mentioned before that Scrum is a framework to set up your development process. It is supposed to be easy. This technique is better used on projects that are difficult, high risk, and uncertain. There are good and bad ways to implement Scrum. Let's look at some good ways.

You need to go all in with Scrum. A little Scrum is a quick way to fail. Factor in time to learn the framework. Your developers got to want to do Scrum. Make sure everyone knows what they are supposed to do. Sounds simple but can be very difficult.

The team needs to be trained in the framework. It helps if a pilot team tackles a smaller challenge first and succeeds. Your team should be located physically together to start. Don't tailor the Scrum process too soon. Do vanilla Scrum until you got it down pat. I am still looking for my first Scrum project. Or more specifically I want to be part of a successful Scrum development project.

The Scrum Way

Our team was working on a replacement for our current production system a few years ago. The development manager had a brilliant idea. We would have a stand up meeting every morning. There were multiple problems with that idea. We were so busy due to being behind schedule. The meetings lasted a long time. That put us even further behind. Eventually the manager was fired, the project was canceled, and we lost our client. Ouch.

I suspect this manager was trying to implement a part of Scrum. That left a bad Scrum taste in my mouth. This does not mean that Scrum itself is bad. Just my particular experience with it. Scrum itself is a framework to create your development process. There are 4 core principles which emphasize individuals, completed functionality, customer collaboration, and responding to change.

There are a number of roles in the Scrum framework. A product owner manages the business. A ScrumMaster manages the team. And the team determines what to do by itself. Yeah. From the outside that seems problem prone. The Scrum activities are to prioritize all work, meet every day, demonstrate success, and search for improvement.

One artifact I find useful in Scrum is backlog. This contains a list of features that have been prioritized. At any given time you know what high priority items need to go in an interaction. I am still not sold on the rest of the Scrum framework. That will require me being part of a Scrum success story.

Open Source Checker

Last year we changed how the reports in our system were handled. Initially we wanted to use an open source library to generate PDFs. However there was a lot of concern over the license. We ended up using a licensed copy of Adobe to do the work. I wonder what other open source code is lurking in our code base?

Protecode has a new version of their System 4 tool out. It searches your project for uses of open source code. Then it identifies the licensing for that code. Talk about solving a problem in one fell swoop.

System 4 does this by having a repository of hundreds of thousands of open source projects. It also has some AI to make sure it does not get confused over code that looks similar to the open source projects. I'd would love to run the source code for all our apps through this thing. I wonder what that would reveal about our code base.

Documentum

Our project has always done some sort of configuration management. It used to be that we threw everything into Rational Clearcase. However there came a time when the customer mandated that we move all documents into a product called Documentum.

Now I did not like Clearcase that much. However Clearcase was great compared to this new Documentum. We hired a person to help us organize all our documents into Documentum. We also hired a Documentum consultant. The documents were moved over. Success was declared. The only difference I found was that it was now hard to access our documents. Years later we moved to SharePoint for document storage and sharing. At least it has a clean web interface.

The current system is scheduled to be replaced by a new system to be developed. One of the tools that the customer requires us to use in the new system is Documentum. That gives me the shivers. Documentatum, in case you did not know, is a content management system from EMC. You check files in and our like source code control. There is access control provided by the product. The latest version hosts the product in a web environment.

Documentum has many APIs which can be accessed from web servers, using Java, by FTP, and a whole lot more. The core feature of the product is its repository. The system is a three tier one, with the repository being a fancy type of database. There is a way to search the repository using their Documentum Query Language (DQL). There is also a Documentum certification. Who knows? Maybe I will try to study up and pass the darn thing. I still suspect this product to add pain to the system.

The Blaze Advisor

Our customer wants a new system to be developed. It is going to replace the system I work on. For reasons unknown, the customer wants all kinds of new technologies to be used in the development of the new system. One of these hot techs is Blaze Advisor.

To tell the truth, I had never heard of the product before. It is more formally known as the FICO Blaze Advisor. It is a business rules management system (BRMS). The marketing says it is for high volume operations. And you can change the rules quickly.

A selling point for this tool is a fast time to market. That would be good to stand up a new system. It also does its own version control of the rules changes. That sounds sweet. The product is brought to you by Fair Issac Corporation. Digging a little deeper, I read that this is a Java based rules engine. The rules go into an internal rules database.

The software was created by Blaze Software. Eventually it was sold to Fair Issac. The most common use of it is by Java programs. This software might be of some use if it lives up to its marketing hype.

Future of Development

Our company is trying to win the work for the project that shall replace the current one. I asked our manager what technologies we thought we might use to implement the new system if we won. There was a long list. And there did not seem to be many traditional coding tasks. One product we were going to use was Business Objects.

To tell the truth, I thought Business Objects were some API using by Crystal Reports. I have since come to find out that Business Objects was a company that got bought out by SAP a few years ago. The premier product of this company is Business Objects XI. This is a big package that includes business intelligence tools.

SAP offers a bunch of instructions ebooks on Business Objects for $19.99 each. Great. I know the company will spring for such training material. But do I really want to get out there and be a Business Objects developer? It is funny. While searching for technical information on Business Objects, I found a job offer for a senior Business Objects developer. It paid $45 per hour. That's not chump change. But it is a lot lower than I thought a SAP developer would make. Oh wait, this is Business Objects. The jury is still out whether I shall even crack a book to learn this stuff. There are also other new technologies in the stack to be used to build the next generation system. More on those products later.

Back to UNIX

My team has been relegated to true maintenance tasks. All we are to do is investigate bug reports. When we figure out what is going on, we come up with an estimate as to how long they will take to fix. We don't even go through with the fix until somebody in charge approves the change. This is none too exciting work.

There is another team on our project which has a massive amount of development going on. They just lost a guy who went to another company. My boss asked me to go join that team with the heavy development load. He did not need to ask me twice.

One of the drawbacks of the new team is that they do all their work in UNIX. Their subsystem loads data given to us mostly by mainframe programs. The code is pretty much C programs running on UNIX. I did spy on a piece of their system that was more Oracle PL/SQL. So I jumped at the opportunity to work on that piece. My request was granted.

Today I just got access to the UNIX development system. Nothing worked out of the box. When I pressed the backspace key, some weird symbol appeared on the screen. I tried to run Oracle SQL*Plus. The program could not be found. Great. Now I got to set up my profile to get the path and other environment variables set. This may be a bit painful. Oh yeah. Did I mention that my text editor is now vi?

Deep Analysis

Yesterday my project manager told me to attend a meeting with another group. These people are planning to write the next generation of our system. I was concerned that I would be talking to the developers that are trying to code me out of a job.

Luckily I went to the meeting and found they are in the beginning phase of analysis. They wanted me to let them know where we get all the data from our system. They also were very interested in how we store internal state of the applications in the database. I had to take an action item on those tasks.

I made sure I did a pretty good job analyzing our system. These people might be my new bosses in a few years. It was a challenging task. Shouldn't there be some database tool that tells you what database tables is a schema are actually being accessed? I don't know of a specific one. Do you?

Agile Success

A whole host of agile technologies have become mainstream over the past few years. These include refactoring, unit test, test driven development, and even Scrum. However pair programming is stuck in the mud.

One problem is that pair programming is expensive. On the surface, it takes twice as much to do pair programming. It is also not liked much by developers. It might be one of the agile methods that never pan out.

However it is the end results that matter. You want to know immediately when the build breaks. That might mean you have unit tests that automatically get applied. Or a build job checks for errors and emails the right people. We don't have that at our work. We used to. But the build scripts got rewritten, and are not as good any more.

Client Connections

You need to understand that every time you meet your client, it impacts the relationship. Clients want an emotional connection with you. You need to understand their expectations to be able to meet them.

The experience the client has must be positive and special. How do you ensure that? Show passion. Be committed. So how do you make sure your employees have passion and are committed? Put them in the right roles.

Be sure to put in that quality time with your clients. Otherwise another company will get a better relationship with your client. Then you lose clients.

Developer Coverage

The managers have a policy on taking vacations. You need to make sure you have somebody covering for you. A developer on our team was taking a massive one month vacation this past month. Then she needed an extra week to care for a sick family member. She was supposed to arrange coverage for her tasks.

She ended up letting our team lead figure out the work coverage. That was a bad move. Our team lead asked two members on our team get familiar with some code changes the vacationing developer was going to make. These members just got familiar with the code changes. In effect, they made sure they could check in code changes on the vacationing developer's behalf. This happened and the software was released to test.

Then the testers needed help figuring out how to do the testing. That was a problem. One ghost developer had checked the code changes in. However knowing what the fix was fixing was beyond comprehension. I got the players involved on a conference call to clear up who was supposed to do what. Apparently the job of the two developers was to gain a better understanding of the actual problem that was being fixed. That makes sense. But you need to be explicit about this if you are giving out directions. That did not happen. This all could have been avoided if the original developer going on vacation had arranged and trained up someone who could provide coverage. That means somebody can do everything the vacationing developer would do if they were in the office. Sometimes the manager policies are actually there for a good reason.

Improving Requirements

Previously I had pondered about techniques to improve requirements analysis. That's why I read a recent Doctor Dobb's Report article on this very topic. To start you need analysts that have skill. This is a tall order to fill. Then you need to make sure you have the right tools. Well we have IBM Rational ReqPro. So we should be good.

The analysts need to identify the business objectives. I know this is sorely lacking for many of our requirements. Often time nobody on the team understands why we are implementing the changes. We also must determine who can speak for the customer. This gets difficult when we have multiple customers that we work for. There is a sponsor, some executives, system acceptance, and different business divisions.

Use cases are a good tool. But they do not solve everything. The analysts need to get down into the functional requirements. Often times our analysts struggle with the business requirements. In that scenarios, there is no chance to do functional requirements well if you are stuck at the business level. You should also do some testing of the requirements themselves to see if there are any holes.

I think I should pass this article to our requirements analysis team. The problem might be the normal one. They are too busy to do anything other than write stuff down that the customer is saying.

Power of Documentation

We have a requirements analysis team. I think they are supposed to work with the customer to figure out what they want. That is a daunting task. It turns out that this team frequently comes to development to ask us what the requirements are. There is something very backwards about this arrangement.

These requirements are then verified with the customer. They are also used by our internal testers, as well as the customer's acceptance test team. It is crucial that these requirements are clear and correct. Lack of clarity means someone is going to get confused. This confusion is a source of trouble. Customers will think they are getting something else. Testers will think the implementation is not correct.

One thing is for sure. It is best to have the requirements correctly documented during the requirements analysis phase. Unfortunately this is not an easy task. And therefore it is not always the way work gets done. We must still strive for this optimal setup for design and development.

Work Assignments

Today was the last day at work before my week of training. I actually completed my tasks in the morning. However I did not want to get bogged down with any new jobs prior to my training. So I stayed low for the afternoon. Luckily nothing popped up.

I have found that this is becoming a pattern with developers on my team. There is never a reward of leaving early if you work hard and get your tasks done. Your reward will be more work. More often than not, that new work will be something that keeps you late into the night.

There is no specific reward for getting done early and taking on new tasks. This is a bad setup. Developers are smart and will make sure to minimize such "rewards" for hard work. I don't have the answer on how to fix this problem. Because I am one of those who does not volunteer for extra tasks that much. Why do it? It just does not make sense. Just saying.

Screaming to Refactor

I am in the middle of coding some change for our next incremental release of the software. After implementing some changes in a stored procedure, I ran my tests. Something was still not right. I traced it down to a trigger calling a stored procedure. It was undoing my changes on the fly. I needed to make another change.

When I got into the other stored procedure, I was lost. The procedure was 850+ lines of code. There were nested IFs that were six, seven, and even eight levels deep. I was around when this procedure was changed over the years. And I still was getting confused over the thing. I decided to print out the code, and line up the IF and ELSEs.

My goal was to refactor this massive procedure. The plan was to break down this monster proc into many subroutines. In the end, the main procedure got down to 150 lines of code. It was much easier to follow. Of course all the lines of code went to small subroutines. I needed to do a bit of regression testing to make sure I did not break anything. With a change of this magnitude, there are going to be some bugs introduced. My unit tests helped flush them out. I am leaving this procedure is much better shape. I am proud.

Forced Management

We have a quick turn around release coming up next month. The project manager provided the high level schedule to everybody. That was a good move. I am looking out for myself. The scheduled time for development is coming up quickly. But I had not seen any preparation done for this task.

The work had not been divided and assigned to developers. The plan for configuration management of the changes had not been hashed out yet. I gave my team lead some time. But nothing was going down. So at a manager's tech meeting, I started asking some questions.

I asked one of the leads how the configuration management was going to be done. We figured that out during the meeting. Then I asked my team lead when he was going to do the assignments. He said it was already done. I told him that nobody on the team knew what their assignments were. Essentially I informed him and the group that nothing was done. We also hashed out the assignments during this meeting. The meeting ran an hour longer than normal. But we got the essential decisions for the next release done.

Should I have waited until the last minute, allowing none of these things to get done? No way. Then me and the team would have been working nights and weekends. Should I have taken the team leads aside individually and told them they needed to get their act together? Perhaps. I could have made the decisions get done. But then I would end up having to do this for every release. I figure I can embarrass the guys a bit by calling them out in a meeting. Perhaps the next time they will be proactive without prodding from me. Maybe not. But if the next release comes around and this work has not been done, I will have to get even more forceful. I will have to call my own special meeting with the big bosses and inform them that some people are not doing their jobs.

Yes I might be a pain. But this is pain with a purpose. I want to make sure planning is done before it is too late and I suffer. The rank and file developers love me because I am looking out for myself and them. The responsible team leads don't like getting called out. But I make it easy. Do your job and I won't bother you.

Grunt Work

A few weeks ago I got an e-mail from a manager in my company. He wanted to know the status of a printer he bought for our office. I heard the thing was dead. So that is what I reported to the manager. This seems to infuriate him as he thought the thing had been in use during the past year. Now it was my job to get the thing running.

Here is the problem. I am the senior guy on my project. That means I deal with a lot of emergencies from the customer. This keep me at work for long hours every day. How can I make time to get a broke down printer working? I like to apply balance to everything. And I also count the costs of choosing different tasks over each other. After a while I was spending too much time explaining why the printer was still not working to the manager. Thus I made it a priority to fix it.

I went to the local computer store to get some parts. Then I found some documentation online on how to setup and debug the printer. Doing these chores meant that I had to skip some meetings where I normally provide all the information. Let's just say those meetings did not go well today. I had a good excuse though. A high level manager wanted his this printer up and running. Finding the printers drivers was not that hard. It was tricky to figure out which things I needed to rip out of the printer to ensure prints went through fine. This is just part of the drudgery of being a developer. People assume you can do sys admin or help desk work. Since I am technical, at least I can. The printer is printing fine now.

Career Programmer

Got a gift card from Barnes and Nobles book store. So I decided to buy at least one technical book. It was The Career Programmer by Christopher Duncan. This one is not technically a technical book. It tries to help you navigate the politics and such of software development.

I must confess that after reading the first 4 chapters of this book, I was bored as hell. But I invested the cash to buy the book. I needed to get something out of it. Then it hit me. I would start reading the chapters from the end of the book toward the beginning. And this is working for me now. It might get boring again when I get to the middle of the book.

The themes I have read so far are simple. Understand that companies are about business. If you can arrange to make your boss look good, and further your goals as well, you win. I will fill you in when I complete reading of this beast. Right now I cannot recommend that you purchase this book. There has to be better material out there.

True Understanding

Recently the customers informed us that their most important problem had not been fixed. My manager called me to appease the customer. I took a peek in the production environment. Yes the data was messed up. I guess the last fix did not do the job.

My boss was worried that the customer was going to continually think that the problem was unresolved. So he had me meet with the customer to define and document exactly what they wanted. I speak their language. So it was clear to me. I just wrote down all the unwritten and unsaid assumptions that I comprehended.

In the end, I came up with a 4 page document. We met to ensure this document was correct and complete. My boss asked that the customer and I agree on any unusual boundary cases. So I discussed and documented what my data correction script would do if it ran into unexpected scenarios. The result was still 4 pages of documentation.

Now most of this documentation was just regurgitating the basic information that I and the customer know. The reason for this document was that none of the managers or executives know the basics. The testers for the most part do not have a strong understanding of the basics either. I was reminded of this as we entered testing of my script. However they did get a solid tester on the scene. He just needed to learn some of the business rules before he could make heads or tails of the testing required. Our team loaned him a developer to assist him, but this guy needed more help to get through all his tests. Luckily this was a high priority task. So I was directed to make time for it.

Good Estimates

Producing accurate software development estimates is an art. These days they mostly seem to be wrong. How can we correct this pattern? Start by defining your project scope. Without that you are doomed to fail. Period. When the requirements change, so does the scope. You then need to estimate again.

Once you have the documented requirements, locate all the unknowns. Overestimate these items. Put together a list of deliverables to manage expectations. Remember to cost in security the first time around. There may also need to be time factored in for developer training.

This might be obvious, but you need a lot of time for testing. The current fix I am doing requires double the amount of time testing as it does coding. This should be the norm and not the exception. Get your developers to agree to the estimate, and more importantly the deadlines.

Add some slack in, no matter how well you think your estimate is. The estimation phase is the toughest one. Don't cave in to pressure to reduce the estimate. That will only lead to disaster.

H1-B Visa Pay

People brought into the company under an H1-B visa make less money than US citizens, right? This is another ploy like outsourcing to bring the salary of US citizens down lower. Here is something interesting. Recent research from the University of Maryland shows that the opposite may be true. H1-B visa workers make more money than their US citizen counterparts in the IT industry.

The study took education and experience into account. It found that H1-B visa holders made about 9% more in pay than US citizens. This is the inverse of the situation with green card holders making 13% less than US citizens. The UMD findings contradict other studies and information previously available. Back in the early 2000's, they found H1-B visa holders making $75k average salaries.

Why is this so? One theory is that companies are getting specialized skills from outside the country, and they need to pay to attract the talent. The H1-B visa holders are also temporary workers. Temp workers in general make more than long term employees. More than half of all H1-B visas are for IT work. Maybe their presence is not all that bad for the locals.

More on Jobs

Software development is a field that is easy to get started in. You can download some free tools. And most of them will work on a normal PC. Get busy working on a product. If you don't think you are ready for that, try helping out on an open source project.

You don't even need to start out coding. I would recommend it. However you can do some testing or documentation work first. There are some technical tasks that are not hard core coding. For example, you could develop a web site.

Learn to program to an API. Become proficient at developing mobile applications. These are good skills to have. If you cannot get a first job as a developer, try working for a non-profit organization or a small business. Alternatively you can get a regular job, then look for ways to move into your company's tech side.

Doing some hand-on work can help make your resume stand out. This is crucial for getting that first real development job. I wish somebody had told me about this when I was in school. Luckily I did end up at an internship which gave me a great resume upon graduation from college. These days you need all the help you can get to enter the job market.

Getting a Job

So you want to be a computer programmer. How do you go about doing this? The job market right now is tough. You got to stand out somehow. I just read this blog entry on how one guy successfully got hired.

You need to have a goal of becoming a great programmer. Go to college. However don't have a goal to get good grades. Get good skills instead. Make sure you do go to college. It can be a community college. But don't cop out and go to some institute like Devry. You will end up doing documentation or help desk work.

Here is another surprising misconception. Your major does not matter that much. Choose a technical degree. But it does not have to be computer science or computer engineering. Do join user groups and attend conferences. Get your social media on. When you apply for jobs, have a personalized cover letter. It would also help to customize the resume to address the job requirements as well. Good luck

Software as a Service

Software as a service is a hot topic these days. The main selling point is that you can quickly get high quality products developed. The only problem is that it is hard to find developers with the necessary skill sets to do the work. Such developers need integration skills.

Outsourcing in general is a difficult task. Like many software development efforts, IT often fails in their outsourcing implementation. Know that software as a service is a kind of outsourcing in itself. Security is important in the software as a service world. Normal DoD security audits may not be sufficient to ensure your security is tight. You must test the security of the vendors you choose.

Software as a service depends on the Internet. So by definition there will be downtime. You need to prepare for this in advance. Make sure incoming mail also gets routed to an alternate system. And the outgoing mail backup should always be ready to go. Test your data recovery plans. And it would be best if you were in control of your own DNS entries.

Code Done Right

I have this task to complete. The goal is to correct a lot of data corrupted in production by some bugs. The actual SQL is not too difficult. Understanding the business logic is most tricky. We had a meeting with the customer to confirm the requirements. Based on the first meeting I banged out a script in no time.

Now I made sure I did my script right. The main routine just makes a lot of calls to other functions. Those functions are ones that I wrote myself. They are in the script as well. However the main routine just implements the logic calling other routines. All the routines trap exceptions and deal with them to ensure the script will run on.

Later we found out that there were some additional requirements for the script. Now the tough business logic became even tougher. However the way I set up the script helped make these new changes a breeze. There was a need for a new function or two. But the main script just needed a line or two tweaked. I had set myself up for success. With the time saved I assisted some other developers who were swamped with their full work loads. That's smart.

Dedicated Administrators

For the past 10 years or so, we have had a dedicated system administrator at our computing center. They were responsible for our specific system. It was easy. If we needed something done on the back end, we would contact this person.

I got a disturbing email from the person today. They are now being taken off the job. It is part of a enterprise wide shift in how work gets done. Instead of specific people being responsible for each system, the whole system administration staff if going to be responsible for all the systems.

This means staff unfamiliar with our system will be matrixed in to do the work. While this might work for stable systems with straight forward standard operating procedures, I bet this will not work well with our system. There is a lot that the administrators pick up over the years. And it is hard to train this instinct. I think we are going to have to suffer for a while until they realize that the new plan is not working. Great.

A Work of Beauty

The customer wanted some data in our system fixed. A prior bug fix did not resolve the underlying data corruption caused by the bug. They were demanding this be resolve as our top priority.

I got called in because I know the system well. We had a meeting where the customer told us the requirements. People get nervous when things like this are just rattled off. So a manager recommended we document the requirements as we heard them.

After a while I called up the manager to ask who was going to write up that documentation, and whether it was going to be a team effort. Good thing I called. He said he wanted me to do it. Better to hear about this when I called than as a surprise at the last minute.

Luckily I was fully engaged with the customer when we went through the requirements clarification. I put together the flow of how our data correction script would run. I added all the details so that somebody familiar with the system would know exactly what we were doing. Got a tech guy to peer review the work. Then a manager added section titles. This document was becoming a good looking thing.

Today we had our first set of meetings with the customer. This one was only with our sponsor to get the game plan for discussing the document with the end user. Our sponsor was very pleased with the document. It read easily. And it captured all the details of what we talked about during our requirements gathering. I was very proud of this document.

Happy Camper

It is Friday afternoon, and I am loving life. Sure it is nice that the weekend is upon us. However I am smiling for a different reason. I got assigned to a high priority problem. No. That alone is not cause for joy. However the fix involves some interesting logic. And I get to code the whole thing myself.

I started with an empty text file. Well I actually started with a small template. But it had no functionality in it. Then I started coding away at the requirements. Yes. I actually had documented requirements. I wrote them. Spoke to the customer. Got assigned to document what I heard. Now I can code to spec.

Here I am, writing nice tight routines. They call subroutines. And guess what? I get to code the subroutines as well. There is actually enough time in the schedule to get all the work done. There is time to adequately test the functionality. I think they got a sense of the complexity when I spoke to the customer about their requirements. I kept going through significant scenarios until I understood what they wanted. There are a lot of combinations, and therefore many scenarios. Those will all be turned into unit test cases.

I just like writing code. It is nice if it is new development. It also helps that the customer desperately needs this code to be correct for them to do their jobs. People are counting on me to deliver. I actually have a reasonable schedule to do my work. You bet I am happy. This is such an unusual situation for most software maintenance work. So I am here on a Friday afternoon. I am writing code and not looking at the clock. Why go anywhere else when I am having so much fun?

Conference Call

I saw a new high priority customer trouble ticket come in. It got assigned to a junior developer. Our team lead said he would help out as well. Then the test team shared some of their findings. I was hoping all was going well. Then I got the dreaded invite to the conference call.

Reluctantly I dialed in. The boss asked whether this problem was related to any other fixes we recently deployed. I tried to stay out of this. People were trying to recall what changes went in to fix what problems. They were also trying to determine whether any of those changes were incomplete.

Finally I could not take it any more. I said we really needed to get back on track. Somebody should find out whether what the customer is reporting is actually happening. Then they should find out why and fix it. After all that we can then investigate how such a problem slipped by. Eventually the boss and the team lead agreed. Then all the developers started saying they were unable to work this weekend. That's when I knew our conference call had become broke down again. Luckily I was able to switch to a higher priority task before conference call number 2 started up on this problem.

Maintenance is not really that hard. You talk with users to find out what they are experiencing. Then find out what they are expecting. Determine if their expectations are valid. See if you can make the problem happen. Then code a fix to make the problem go away. If you are mature, go a little further to find out how the problem can be resolved. Anything beyond these simple steps are going to be a waste of time. Seriously.

Middle of the Function

A coworker has been struggling to resolve a bug in our system for about 5 days. Part of the problem is that he keeps getting distracted by other work. However he made a goal of knocking this thing out by the end of the week.

Three were strange things happening. Perusing the code made it look like those things should never happen. So this developer put a bunch of breakpoints in the code. Actually he inserted a bunch of message boxes to slow things down and alert him to what was happening.

He traced the code down into one particular call to a funciton. The function looked simple. It was supposed to retrieve a string from the registry. However it was coming back with the wrong string. So he traced in with the debugger. That's when he saw what was going on. In the middle of the function, somebody put some code to return a constant string. All the other code below it was not getting executed.

You would think that the compiler would warn you about the unreachable code. It probably was. However that was getting lost in the million other warnings that race by in the build. Your eyes can deceive you when you trace code. However the debugger does not lie, not usually at least.

Desktop Environment

I have been working on a high priority problem for the customer. The behavior is strange. The software just does not work on some workstation. It generates an unknown exception. My boss told me to look into the version of Microsoft Office.

We use Office to run the reports. Everybody has Office 2003. I drilled down to the DLL from Office that we use. Everybody has the exact same version. But some people's stuff works, others does not.

After a while the customer got frustrated. Luckily they wanted us to stop researching this problem. They have other teams that manage the configuration of all workstations. Now I am only going to assist the workstation folks to figure out the delta between the workstations.

We got to have a stable workstation. Our documentation lists the required software and versions that we expect be configured on the workstation. It is tough when the customer manages the workstations. That means there is a variable outside of our control. But I guess that is life.