Pencils Down

This weblog is about my experiences in software development

Browsing Posts tagged Process

Project Ending

No comments

The project manager for our project is leaving. She is a contractor. The project is complete so they are closing her contract. From 50,000 feet it makes sense. Kind of an accountants dream – have people on board just for the time you need them then they go away. She had been here a little over a year.

I have seen this happen many times. The “worst” was a 20 year systems engineer at a big DOD contractor was allowed to retire early otherwise his pension would have decreased kind of per day he stayed on. Again, quite the accountant’s ideal – nice little annuity math that can be produced in a spreadsheet instantly.

My first inclination is that, no, they won’t really do that. How can the company recapture the knowledge that is sitting in these people’s brains? All the big and little nuances about how the company runs, works, operates, gets things done. Gone in the time it takes to sign the closing NDA. I don’t think reading about reincarnation lately has made me feel better about the loss.

Afterwards started to think like the Sherlock Holme’s approach (quite mangled): “After eliminating the possibilities, whatever is left must be true”. I think this means the companies have a kind of planned obsolescence to their business model. They WANT to re-evaluate, start again, rethink, redevelop.

Seems like a gutsy plan. Who am I to argue? The current company just celebrated 150 years. The DOD contractor has been around about 50 years. Just seems inhuman(e).

Recently our smaller sized project went through a final test cycle (with customer reps present!).  So, of course, for the last two weeks we have been flooded with feature requests that “have to” be done for this release.

Any discussion about whether this was a good idea or not was thrown aside:  “The customer made this request.”, “It has to work this way or we can’t release”, etc…

There has been a recent change on the test side of the world, but that person has many years of doing this under their belt. Similarly at upper levels of management of the project: they all have many years of doing this. Yet, somehow, lots of features show up at the last minute with little to no documentation as to actual requirements or needs.

I guess I should be used to this (having many years of doing this myself), but I am always flabbergasted.

And of course, the testing did not go well.

Oh, by the way…

No comments

This is never a good thing to hear in the software (maybe any) world.  The follow-on sentence will usually melt away any ideas you had about being on time, on budget, taking vacation time, you name it.

For a project here it was switching operating system to Linux from Windows.  Not particularly bad since they are running Java all-around, but there is always some wierd, buried aspect of Java that you are using that really doesn’t work the same way on Linux versus Windows.  There is also a lot of testing that has to be added in to account for the o/s change to make sure all the programmers didn’t add in Windows-like tendencies: file i/o, file naming, network access, threads, etc…

So, of course, once the first blow was digested the follow-on statement came out that we need Active Directory, which is a Windows product, so need another computer just to run that, but we need everything on a small footprint, and it was going to be a blade server, but is looking to be a standard server, …

I wonder if these statements were well-known, decided months ago and we never were in the loop or did someone have an idea in the shower or maybe had an idea in the shower months ago and never told anyone?  Assuming these kind of things are not limited to software, I am guessing the latter: someone was sitting on a decision that is/will wreak havoc with the rest of the world but has very little affect on them.  So, why mention it?

So, you are working on this super-duper set of software in the security (crypto) space.  You are using all the latest software techniques and tools.  You have a systems group that knows how all the supporting software and hardware works.  You design the ui and some underlying behavior and have some questions as to how the end user might do something.  WRONG!

If you think about it the number of end users for your product that exist in the world is small.  Then they have to be articulate, open to change, etc…  This limits the number to probably a handful.  Then you have the small detail – they have to be available.  Any person who meets the above criteria is likely on call, in the field at all times.

So, you get proxies:

  • trainers in the States (again who aren’t occupied and likely in high demand due to low numbers of real users),
  • consultants who did they job some years ago (and are therefore dated in their knowledge), and
  • long time employees (who have always had this 3rd hand point of view)

For those of you who have developed code I assume you are just as amazed as I am.

CMM

No comments

The contractor I am working with advertises as being a CMM Level 5 developer.  My understanding is that is a big deal.  To have such highly repeatable processes that are fully circular evaluating and correcting faults inline.

Then the project lead told us how it really works: based on the project type, size and duration you could be anywhere from a 3 to 5.  For example, a custom product, less than a few years and under 10 people is a 3.

I think it’s odd that everything at a company isn’t level N or M.

Started working in an unclassified area of a government contractor.  We are developing a web app using Java/JSF on Spring against an Oracle database.  Pretty standard stuff.

The wierd part is the process must still work in a waterfall enviroment.  Here we have a classic Agile development environment and the constraints of the company dictate against anything non-waterfall.  Even a continuous build is a no-no.  Heaven forbid any test driven devolopment ideas find their way into the system.

The rigidity is painful to the development manager.  As the new guy, I looked over the progress to date (use cases, high level design, etc…) and pointed out a few skips.  The skips can not be mentioned or written down anywhere.  If they are recorded then the dev mgr is called to the mat as to why the process failed to catch the errors.

Looks to be an interesting experience.