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.
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.
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.
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.
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.
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?
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.
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
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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?
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.
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.
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.