Scientific Method

The basis of the scientific method is recording data. To record data we need to establish metrics.  Without standard units and measurement there is no physics. Without metrics there is no software process. Without records we have only myths.

The other day I was speaking with a developer with about 8 year experience. I asked, on a software tool project, using the C programming language, with an expected size of 10K lines of code (LOC), what would be the average LOC per day. (He did not ask as to how I defined LOC. I broadly put it as the number of executable LOC - STXLN in the tool QA-C from Programming Research). The amazing answer: ~400 LOC/day!!!

In the Tools BU of Acme Technologies we constructed and renovated programming tools. My experience was a rate of 8~10 LOC/day. We had recorded data. We did not depend on myths.

Have a look at the data for the project gpsd — a GPS service daemon. A code-only size of 51,064 required 12 person-years. Assuming 22 working days/month, this works out to a rate of 16 LOC/day!

PS:  An earlier post on keeping records

Bolt or Jackie?

I was in conversation with someone who said he had experience of agile methodology at one of the companies he had worked at.

I asked him to describe agile development. The first statement that he made was, "It is for fast development."

Not quite correct. Agility is not the same as speed. Usain Bolt is the fastest human. I doubt if he is anywhere near the most agile. Arguably the most agile would be Jackie Chan. Though Mr. Chan would undoubtedly be quick, I doubt if he is a world class sprinter. I doubt if Mr. Bolt would qualify for the Jamaican acrobatics team.

Agility is the ability to respond to surprises. It needs muscular coordination, quick reflexes, flexibility, excellent sense of balance, and sixth sense.

A software process that focuses on speed wants to anticipate all surprises. It is about risk minimization. It invests in up-front detailed design and the associated processes to ensure that the plan is followed. It needs a clearly marked standard track to sprint down.

A software process that focuses on agility acknowledges that the only thing that can be said in advance about surprises is that they will occur. It is not about speed of development but speed of response to surprises. Speed of response to surprises needs leadership with a mindset that is willing to accept surprises - not sweep them under the carpet. It needs leadership with a mindset willing to invest time in keeping the code malleable at all times.

When I asked my interlocutor to name some of the agile practices, the only one he mentioned was morning ten minute stand-up meetings. Questioned as to how it was determined if the day's commitment was achieved, or not, there was no answer. (Expected Answer: unit tests that pass.)

Malleability

Malleability is that property of a material that allows it to be easily shaped. Gold is malleable. Stone is not.

Code should be malleable.

Polymorphism (from the Greek poly meaning "many", and morphe meaning "form, shape") adds to malleability. So do unit tests. Coupling destroys malleability. Cohesion enhances it.

Reluctance to modify code is a sure sign that malleability is being degraded. Attend to it. If it is hard to do now, it is not going to easier on its own.

Code that is not malleable become "Bhoot Banglas". Code that is not malleable is code that is petrified (from the Greek petro for stone). Petrified code leads to petrified code maintainers.

E-mail Practice & Code

I remember reading somewhere: Software reflects the organization that made it. The quality of  the code says a lot about the practices of the organization (company, team, individual) that created it. After all, quality of code is the result of software practices.

The opposite is equally true. The practices of an organization say a lot about its software practices.

Practices are the result of values, of world views, held as individuals and, in the aggregate, by an organization.

One practice that I have found to be specially revealing is the handling of email threads.

Anti-Patterns

• If threads need to be measured "by-the-yard", will functions in the code be any different?
• If subject fields are not indicative of the contents of an email, will function and variable names be any different?
• If mail threads are not forked, will code be re-factored?
• If sentences run on and on, will the code be any less convoluted?
• If paragraphing is poorly done, will code structure be done well?
• If mail is not self-reviewed, will code have unit tests?
• Most importantly, if the CEO and CTO tolerate sloppy email, will they do anything about sloppy code?

Takeaway

Code is written - just like a document is written. Code is constructed - just like a document is constructed. Both require thinking. Careless thinking for one is a good indicator it will be so for the other.

Movies & Temping

Consider movies. The big studios employed actor, directors, story writers, ... Even owned theaters. The days of the big production studios, whether in Bollywood, or Hollywood, are long over. Earlier directors and actors signed on with a studio. Now they sign on for a movie. They refer to them as projects. They are temps. The big studios have been replaced by a movie-making ecosystem


Consider credit lists. Movies these days have credit lists at the end of the film. And they run for miles. I do not recall earlier movies having credit lists at the end of the movie. I suppose it is a result of the new model of movie making. Temps require to get credit for their work. They need to be acknowledged as having been part of the project.

The same I believe is happening in software. No, neither Infosys, nor TCS, nor ...  are going to disappear any time soon. But they will increasingly resort to temping (I believe some of them already do). Their margins are going to get squeezed. They just will not be able to afford talent sitting on the bench.

My advice to those preparing for a career in software: forget it, there is no career. But there is a profession.

Networking does not mean partying. It means making other professionally more than superficially aware of  your skills; and being more than superficially aware of other professionals' skills. It means getting to know other professionals, professionally.

Be very prudent with your personal finances. Avoid the debt trap. The days of the regular pay-check, for years and years, is over; so are the days of regular increments - be prepared for decrements.

Try and acquire some marketing & sales skills and communication skills. You are a marketing and sales person. The product you are marketing, and selling, is YOU. And be ready to modify the product.

Read & digest The Clean Coder: A Code of Conduct For Professional Programmers  

 

Pre-Conditions, Post-Conditions & Unit Tests

Recently I wrote a class for program flow-graphs. Writing unit tests, it turned out, required more effort than the unit tests that I had written for other classes .

I was aware that when writing functions one must document the pre-conditions and the post-conditions. These I implemented as asserts. I usually felt that these were adequate. But when it came to the program flow-graph methods, the set of asserts was turning up to be just too messy

As I mentioned, the development of unit tests was turning out to be more difficult. The program flow-graph object to be used for the test had to be decided. What it would be transformed to was to be worked out. I found myself putting these down, in the test case file, as a file comment block. While doing that, I realized I was effectively specifying Pre-Conditions and Post-Conditions. I was saying, "Given this program graph object as the input, some set of attributes should change, and some set of attributes should remain invariant".

Light-Bulb event: Unit tests are statements of Pre-Conditions and Post-conditions.

What about asserts? I now regard these as micro unit tests that are embedded in the code.

PS: I hope to be more frequent in my posts in 2014:-)
Happy New Year.