%%unconventional code readability tips – for prod support

[[The Art of Readable Code]] has tips on naming, early return (from functions), de-nesting,  variable reduction, and many other topics…. Here are my own thoughts.

I said in another blog that “in early phrases (perhaps including go-live) of a ent SDLC, a practical priority is instrumentation.” Now I feel a 2nd practical priority is readability and traceability esp. for the purpose of live support. Here are a few unconventional suggestions that some authorities will undoubtedly frown upon.

Avoid cliche method names as they carry less information in the log. If a util function isn’t virtual but widely used, try to name it uniquely.

Put numbers in names — the less public but important class/function names. You don’t want other people outside your  team to notice these unusual names, but names with embedded numbers are more unique and easier to spot.

Avoid function overloads (unavailable in C). They reduce traceability without adding value.

Log with individualized, colorful even outlandish words at strategic locations. More memorable and easier to spot in log.

Asserts – make them easy to use and encourage yourself to use them liberally. Convert comments to asserts.

If a variable (including a field) is edited from everywhere, then allow a single point of write access – choke point. This is more for live support than readability.

How do global variables fit in? If a Global is modified everywhere (no choke point), then it’s hard to understand its life cycle. I always try to go through a single point of write-access, but Globals are too accessible and too open, so the choke point is advisory and easily bypassed.

Advertisements

how important are QA/BA/DBA/RTB ..#my take

This is a frank, honest but personal observation/reflection of the reality I witnessed. We should always bear in mind how (in)dispensable we really are to the business.

+ Many wall st trading system development teams have no QA personnel so developers do that. I did that.
+ Many wall st trading system development teams have no BA, so the project lead or key developer do that. I did that.
+ Many wall st system development teams have no RTB (Run-The-Bank, as the opposite side from Build-The-Bank) support team, so developers do
that. I did that. RTB can probably handle major FO (front office) apps but a lot of apps aren’t in that league.

+ Each wall st trading system development team I have seen never has a hands-off architect. If there’s an architect this person is first a coder then an architect.

+ Some wall st trading system development teams have no need for a DBA or unix SA (system admin). Without going into specifics, much of the expertise isn’t needed before release to production if (not a big if) developers _can_ build their apps themselves. In rare cases developers need some tuning advice.See also http://bigblog.tanbin.com/2010/12/hands-off-manager-according-to-lego.html

– However, proj mgr is crucial, every time. Most wall st systems are interdependent and extremely quick turnaround, requiring non-trivial communication, coordination, estimation, monitoring. I feel half the time the key developers don’t play the PM role.

BAU vs green field – Wall St

My Citi mgr divided my work into ProdSupport + Greenfield + BAU i.e. (strategic or quick) enhancements on current production codebase.

In ML, effort is divided into BAU 66% + 33% Greenfield

GS is 75-25

One of the hardest part in Greenfield is replicating BAU behavior. The closer we get to prod release, the more we rely on prod system knowledge. Those nitty-gritty BAU behaviors become necessary features and show stoppers.

I think recruiters generally see Greenfield as more attractive. More design involved. More experienced candidates required.

A friend said green field becomes stressful as release date approaches.

Fwd: prod support emails; learning big codebase (Citi munu)

category: GTD, cope

Nara,

In your first 3 months, do you have bandwidth to study half the prod support emails? What type of issues do you choose to look into?

I first chose to follow those issues related to my project and my sub-system. It turned out my sub-system shares a lot of common code with other sub-systems, common code like messaging, caching, javascript, env set-up in ksh…. I was reluctant to look into them. In hindsight, I feel it’s best not to get hung up on those since they couldn’t help me show progress in the first 2 weeks. Expectation on me (from the Lab49 project manager) was to show progress every week.

I chose to follow issues about those relatively “simpler” modules. I chose to give up on any discussion thread I can’t easily understand, as they require too much investigation, and I can’t afford to spread myself too thin. This might be a poor learning habit.

I chose to focus on the autosys setup, because that’s how our servers are started, so I can trace to see the start-up parameters.

I realized some colleagues are busier than others, so I chose to bug those (which?) colleagues and spend more time on the subsystems they know better. How fast I learn is proportional to how much help I get.

I spent a lot of time setting up remote debugging so I could investigate a live UA server by myself. This is a big investment of my time, and manager doesn’t always see the value. I took the risk of this investment. I think it paid off.

I have a poor habit of focusing too much on environment set-up including IDE, build process, access to log files, access to database. I guess many fast learners do not get hung up on those. Now I feel as consultants I must deliver from the first week or so. If I invest time upfront setting up my tools and environment, it might help my productivity later, but initially it will hurt my productivity. One of my managers (the Lab49 project manager) had just a few weeks to form an impression of me as somewhat slow.

You mentioned once that due to the asynchronous nature, you spent lots of free time text-searching in the codebase. This is another personal investment that may not bear fruit? But it did bear fruit?

Generally, I found it challenging to understand most prod support issue. They always involve some system knowledge unknown to me. The learning process is a snowball process – you build up a good understanding of some system, and use that knowledge to understand related systems.

How do you start your snowball?

BMC patrol, Microsoft MOM

hi, Tan Bin

Varies Knowledge Module comes with Agent, base on the role, other than monitor OS itself, you can purchase and configure Knowledge Module to monitor applications/services running on it.
it is similar to Microsoft MOM. every new application come on, MS will develop Management pack to install and moitor it.

Z Hao