Getting Agile

I just finished reading an eBook on agile development. There were some key insights in there that I want to share. To start with, you need to identify the backlog of work to do. This includes both new features and bugs to fix.

When you estimate the time needed to complete the work, focus on user stories instead of requirements. Count developers for only 6 hours of productive work at the max. I personally would only schedule based on 4 actual productive programming hours per day.

Development is split up into sprints. It is wise to have a Sprint Zero to get your team organized. Some sprints should harden your system by focusing on bug fixes alone. We do this on my current project.

Require progress updates once per day. When you finish any given sprint, review all the tests. Hopefully your tests are automated for optimal test team performance. Waste is defined as any activities that do not add value to the final product. You are going to want to trim waste with a vengeance.

Finally there are only two values for percent complete that matter. They are 0% and 100% done. Anything in between is best thought of as 0% complete. Radical.

Skills Required

I recently met up with an old friend that is a developer. He has been looking for work for a while. The challenge is often that employers want developers with experience in 8 to 10 technologies. Who has that type of skill set?

Yesterday I read an article that seems to confirm this phenomenon. Developers need to know a lot of different things. This includes SOA, OOP, and UI development.

It makes sense that a developer might need to know more than one programming language. That gives you additional insight. I don't know whether it makes sense to know a little bit about 10 different technologies. That is a generalist that specializes in nothing.

Code School

The people at Envy Labs have opened up their Code School. It is an online learning site. The goal is to "learn by doing". They have short videos, along with hands on exercises. You got to pass some sort of challenge before moving on to the next section.

Right now they have a course on Ruby on Rails. It costs $45, a discount from the normal price of $75. Some other courses that are coming soon include jQuery, HTML 5, and CSS.

I am not sure whether this is a good deal. If their hands on technique can teach me stuff in just an hour, I might buy in. It helps that my employer foots the bill for my technical training. If it was my own money, I don't think I would be buying though.

The Software Architect

A lot of developers aspire to become a software architect. The title sounds impressive. And you figure an architect is going to be making a lot of money. I found it humorous that one team on my project decided to declare itself as the architects. Even though such antics are humorous, I think there is some validity to moving ahead by becoming an architect.

I read an article on how real life people advanced to the software architect position. One factor was getting involved with new technology early on. Another is doing publishing or public speaking. You must have top notch communication skills.

Business Objects

I have a coworker that is in training for Business Objects this week. It might be a good time to be learning. SAP just did a major upgrade to Business Objects 4 recently. SAP bought Business Objects 4 years ago. Now they are moving forward with the product.

There have been some job postings recently that require Business Objects Universes experience. Well that term is obsolete in the new version. That functionality has been grouped in with other functions into the Business Layer.

My coworker previously attended some training on Crystal Reports. She got a bit of Business Objects training back then as well. What's the difference between Crystal Reports and Business Objects you might ask. Crystal Reports, like Dashboarding, is one of the interfaces to Business Objects. It is a simple one at that.

I hear the new Business Objects has event processing down pat. Perhaps I shall quiz my coworker when she returns and find out the real inside story. Let's hope she learned some of the new Business Objects 4 features.

Getting the Build Working

My team lead asked me to assist a junior developer with their compile problems. The team lead tried to help previously. But our software would not build on one developer's new machine.

I took a look at some of the errors. There were calls to bitmap functions, passing in literals like OBM_CHECKBOXES. I searched around and found these were defined in "winuser.h". That file should be getting included I thought.

So I went and traced how "winuser.h" gets included. I found that it all starts with "stdafx.h", and eventually get included from "windows.h". Then I saw that these header files were present and included on the new machine. They were.

Upon closer inspection of "winuser.h", the literals are only defined if you have already defined OEMRESOURCES. I went through the exercise again finding how OEMRESOURCES gets defined on my machine. It is part of the project. Turns out the new machine had a project file which failed to define OEMRESOURCES for the debug build. Getting a correct project file solved this problem.

The details of the debugging are not important. The process is important. I did most of the investigation along side our junior developer. Hopefully some of this is rubbing off. Next step is to debug why another project fails to build on the machine due to missing DLL dependencies. Fun stuff.