Friday, January 29, 2016

Evolution of reuse/subroutines/functions/services Part 1

This post is a potted history of the ways we have seen reuse work in software over time. It is a somewhat personal history, starting with my first foray into software in 1967. I didn't invent any of this - but was a beneficiary.

The first exposure I had was when I did a summer internship at Gloucester Polytechnic in 1967. We were allowed to get our hands on a real live computer. Paper tape was the only mechanism for getting programs and data into the beast. The programming language was called City and Guilds Mnemonic code. It was an early teaching environment running on an ICT 1900 series computer. We were given the task of using Heron's formula for calculating the area of a triangle. This involves taking the square root of a number at the last step of the calculation.
The really important part of the exercise was writing the square root function in this very low level language. We were instructed to use a Newton-Raphson iteration method. This was quite tedious! After about 2 weeks I finally had this beast working. It was coded on paper tape using a machine like this.

The paper tape device had a useful feature - you could make an exact duplicate of an existing tape. That was how we corrected bugs in the program. Copy the working bit of the code. Stop the copy. Type in the new code. Advance the original to the point where you wanted to continue from and continue the copy. No wonder the square root took 2 weeks.
At which point, the instructor said, "You can't be the first people ever to create a square root function, so why do it again and again? Especially as there may be errors in your version."
He the pointed to a row of coat hooks. Above each coat hook was a DYMO embossed tape label naming a function. Hanging on each hook was a loop of laminated paper tape containing the code for the function.
The procedure was:

  1. Identify the function you need
  2. Locate the coat hook
  3. Take the tape loop
  4. Place the loop into the input side of the tape copy machine
  5. Position the tape on the output side where you need the function
  6. Copy the code from the input to the outside
  7. Remove the laminated tape from the input side
  8. Inspect for nicks/errors
  9. If the original is damaged or showing signs of wear, give it to the computer lab tech to have a new copy made
  10. Either the original or new copy of the function is replaced on the hook.
These physical images have stayed with me since then. And they help me as I think through the pros and cons of different coding approaches.
  1. First locate the subroutine or function (if one exists). The "FIND" step
  2. Make the subroutine/function available to the program. The "BIND" step
  3. Execute the program containing the function/subroutine. The "EXECUTE" step
Of course FIND/BIND/EXECUTE model doesn't tell you how to create good subroutines/functions. But it does provide a good thinking model for what has to happen when you want to use a previously developed routine.
  1. How do I know where to look? Where are the coat hooks?
  2. What searching ability do I have? Can I read the DYMO label?
  3. Do I inline the code (copy/paste in modern parlance)? or do I invoke it (lots of ways)? Inline was all I had
  4. Who has the ability to create new copies? Who are the lab technicians?
In other articles in this series I will look at mechanisms from link libraries, component libraries, shared functions, open source, services, micro-services and associated mechanisms for the FIND/BIND/EXECUTE model

Thursday, December 24, 2015

What do you mean a distant third?

This article showed up in a tweet today. It is really discouraging when a university professor (and a well respected prof from a well respected school). This quote is directly from that post.

"He is not shy about admitting where teaching falls on the list of priorities for most of his peers: a distant third, after publishing articles and landing research grants"

Surely the students are job #1? Apparently not.

Universities don't like to be tagged with the soubriquet "trade school", but for many of the jobs that need to be performed, a trade school is exactly what is needed. I don't need research in statistics to be a better programmer.  I need to learn programming (not computer languages, but actually what programming is about at some level).

Maybe we would have a more productive economy if we didn't bother with this university stuff - or at least as much of it as is required. But then hiring managers would actually have to look at skill, confidence, attitude to determine hiring and not irrelevant proxies like Grade Point Average.

Sunday, September 20, 2015

Work vs Effort

There's a lot going on in my world at the moment. I guess that is normal, but a whole lot of thoughts have come to a collision point. All around the notion of getting stuff done (results) vs effort applied (work).

It's easy to work hard. It's easy to convince people that you have worked hard. But typically what we all want are results. That's a bit more difficult.

In Gut Feelings, (http://www.amazon.com/Gut-Feelings-The-Intelligence-Unconscious/dp/0143113763) Gerd Gigerenzer describes the heuristics of catching a fly-ball. Simple heuristic - keep the angle between your eye and the ball constant. It will arrive where you are! Annoys coaches though. If you apply the heuristic, you amble to where the ball will land, you don't hustle. Coaches should want results, but they seem to want hustle. But hustle is work, catching the ball is a result.

From my own child hood in boarding school, we had daily chores. To be done after breakfast and before the first teaching period. On one occasion I had the job of cleaning the foyer (fancy word for the main entrance where we all entered and left: dirt, shoes and all).  The goal was a clean floor - what seemed to me like an impossible result. So I tried to convince the inspectorate (some sadistic youth 2 years older than I), that my success should be measured by how much dirt I picked up (~= effort) and not by how clean the floor was. It was easy to show progress. Hard to show results.

Fast forward to modern development. I see so much emphasis on frameworks, automated this and that, cool toys,... that we sometimes forget that we need a piece of software to do something straightforward. Let's make sure we deliver what's really important and not measure our progress by the toys we have created.

Wednesday, January 29, 2014

Social Media Bragging Rights?

I am beginning to get very irritated with Google Plus and Linkedin. Surprisingly more with them than with other SM sites (Facebook/Twitter in my case).

Why so annoyed? It seems as if they are developing giant social graphs which are devoid of meaning. I am added to several G+ circles per day. I don't use G+ for anything much, so why anyone would want me is beyond me. However I can imagine that as an entree to expansion of social graph and thus credibility.

How does it happen? G+ just has random people put me in their circles. No easy way to block it seems.

LinkedIn lands me on the add your mailbox to us page. It looks as if that page is in the normal flow, but it is bypassable.

Sad really because we can get value if you use it the way we want to, but as soon as the sites start behaving like this, their utility declines and people stop using them or drift away.

Thursday, June 6, 2013

How much classification is enough?

This certainly isn't new thinking, but it gave me a couple of aha moments. There seem to be 2 ends of the spectrum regarding information retrieval/storage/management. Here I am thinking about things like email, tweets, general information (trivia like).
Do you classify and organize - e.g. lots of outlook folders all arranged neatly with rules putting incoming messages into these folders? Or do you keep them in a giant heap and use search tools/techniques to help you locate critical emails when you need them?
It turns out that philosophies of manging email differ quite a lot from person to person. I used to be an organizer and classifier - until I realized that I could never set the rules up sensibly. Things would get "mis-filed" so it was hard work finding them anyway. Should I organize by date? Should I organize by from (in the inbox at least)? Should I organize by keywords (Oh dear which an how many copies do I need to keep)?
Of course I could take an entirely different approach. I could pile all the mail into a single folder and have very potent tools. But that also puts some significant burden on me. I have to remember the words that might have been used - and their spelling! If I get an email from an English colleague and s/he is talking about organisation and I want to correlate that with some observations from an American colleague, it is going to be tough using just a search method. Search is improving, but still it isn't easy yet.
My natural tendency is to "classify at the moment of use" - i.e. to base my filing "system" around search. That extends to physical filing too - one look at my desk would convince anyone that I don't organize! Of course that drives madame nuts, but that's a story for a different time.
Which are you? Do you tend towards one end of the spectrum or the other?

Friday, January 25, 2013

Context is king in signage

I have started a new project recently. It is a very lkarge one - about 30 work packages, lots of people and significant complexity. As with all endeavors, we have to learn the landscape and learn it fast. After all we are paid to be productive, not to learn. Similarly when we get to a new city, we have the objectives (conflicting at times) of finding the hotel and learning the city.
The big aha observation is that all sign posts are created by people who know where they are. They are not necessarily created for those who want to find things. That's (perhaps) why we have maps and why navigation using something like Google maps works so well. But I digress.

On this project, the work packages are imaginatively numbered wp101, wp102.. up to wp120 for the first release. And then wp201... for the second. Work packages have calendar based deadlines. And of course we have times of day to worry about too. Especially during the work day/early afternoon.

So when there is a conversation in WP116 saying we need to move "that" to 220 what do we mean? Is it move it to wp220? Is it to move the due date out to Februaray the twentieth? Or should it be discussed at the 2:20pm status meeting?

Of course when you have the context, you have enough metadata to figure it out. But when you are a stranger in project land, it requires considerable mental energy to figure it out. The signposts (220 in this case) are used by the people who know, and those of us trying to use them for direction scramble to keep up.

On projects like these, it is not so much of an issue. But in the "real" world, putting yourself in the mind of all of the user constituencies is important. Is this sign put there because the law says we have to have signs? Is it to help natives who need to find quick alternate routes? Is it to embrace strangers/visitors? All of the above?

Monday, January 21, 2013

There's a place for everything and everything in its place - except when there isn't

Charles Goodrich (1790 - 1862) popularized the epigram "A place for everything and everything in its place".  http://en.wikipedia.org/wiki/Charles_A._Goodrich. However I suspect he wasn't thinking about what to do with data. We are accustomed to thinking in hierarchies, that our data are neatly arranged - like an English formal garden. But in reality, what we have is a wild  and untamed data wilderness. We never know what nuggets we will pick up where. What "gifts" flocks of birds excreting seeds will deliver allowing new things to sprout in unusual places.
Organization and arrangement are fantastic and efficient for transactional activities - those things where we, by force of will have designed things. But where we have non transactional, undesigned things we have to adapt to what we find.
This distinction between adaptation to what we find and purposeful design is crucial. If we attempt to impose purposeful design over things we find, we commit a variety of sins:
  • We abstract too early - ending up with meaningless abstractions. After all the ultimate data model has one box and one line. Thing is the box. Relates to is the line. Then we end up with a series of triples. But we can't see any reality in there.
  • We name things that don't really have names. But categorization demands it.
  • We box ourselves in - we put "everything in its place", without considering that actually there are multiple places
  • We throw stuff away because it doesn't fit our notion of predined categories.
We are now in a "big data" world, where we have the opportunity to keep more stuff, where we have multiple classification systems, where we can draw inference from meta-data observation. Yet we still try to impose "design ahead" schemata on things outside of our control. This is often where master data management, large data modeling projects and other attempts to impose order often falter. We argue over nits, create beautiful (but sometimes irrelevant) abstractions.
Let's not forget that there is a place for order. But also remember that sometimes things just are and it is our job to interpret rather than to order.