Wednesday, April 29, 2009

Programmers, or Domain Experts who Program?

The problem is that "programmers" often don't know much about the
domain their programming within. Of course, they have to come to
understand the domain a little bit to build the program. But too often
that domain knowledge is transferred through software Requirements and
Specifications. My boss, JP, once opined that you can write a big,
thick book of specifications and hand it to a good programmer, and get
a working product at the end. Perhaps you can -- if that book
functions to educate the programmer on the domain knowledge of the
program.

In 2004, I gave a talk to Computer Science students at Valdosta State
University about Domain Expertise. I said, back then, that you
shouldn't expect to write a program about a business domain unless you
could also write a book about that business domain.

Just recently, a giant multinational corporation approached my
employer about a software development contract. They know we
understand the domain, but they expect us to outsource to overseas
programmers. I have nothing against anyone who writes code and lives
somewhere else, but it's amazing that this corporation isn't as
interested in the domain knowledge as much as the low pay rates in
other companies.

What you really need are domain experts who also write programs. Like
my friend Aaron Kahn who works with the Naval Research Lab. He's an
Aerospace Engineer -- who also writes programs. When he visited last
year, he was interested by my collection of books on programming. He
knows aerospace engineering first and foremost -- and writes code to
implement the ideas he knows.

Was there really ever an era of cheap programming? I doubt it. Good
software in complex domains is always the result of good comprehension
of that domain. The best place is for that comprehension to lie with
the developer.

Open Source software development tools are so good because the people
developing the software were, of course, experts in the software they
were developing. They were building tools for their own use. This
really follows the non-selfconscious design process described by
Christopher Alexander. They didn't build software because they had
specifications for it; they build and improve their software because
it has a problem, and they just want to fix the problem.

Professional programming, unfortunately, is often self conscious:
somebody tried to write the Big Book of Specifications while somebody
else tries to build it. And, as Alexander predicts, this kind of
process fails.

So, Practicing Computer Scientists: get expertise beyond computing!
I'm growing expertise in telephony -- connecting people for real-time
voice communication. My friend, Chris Vaughan, has expertise in
banking, and in hospital lab management, and some in industrial food
distribution, and probably expertise in other fields.

Sunday, April 26, 2009

"Redeeming the Mess We're In": sermon two based on the shack, taught by George Fuller, New Community Church.

"Redeeming the Mess We're In": sermon two based on the shack, taught
by George Fuller, New Community Church.

About the Introduction, when Mack first meets God at the shack.

The first step is to realize that we're in a mess. Jesus said he came
to heal the sick.

2 Corinthians 5:11-6:2 -- "now is the day of Salvation"

God wants to heal a wound -- sin is one big wound.

We're sometimes afraid to get to know God, because we don't want to
have to give things up, or start to do things we don't want to do. If
we believe that God loves us, then we won't be so worried about
sorting out the specific actions.

Getting up know God, starts with a hug. In the story, each member of
the trinity gave Mack a hug.

Sometimes we hold back from Getting To know God because we have
preconceived notions about God.

Notes on James study led by Frank Green at New Community Church, Raleigh. James 1:1-4

Notes on James study led by Frank Green at New Community Church, Raleigh

Frank Green's teaching --

Martin Luther thought that James contradicted Paul. So Luther didn't
think it belonged in the Canon.

Some believe James belonged to the circumcision sect, that Gentiles
had to become Jews first.

Some people also think I started as a commentary on the sermon on the
mount, and especially the beatitudes.

Lots of Christians were leaving Jerusalem at this time. Both non-
Christian Jews and Romans didn't like Christians.

James 1:1
By referring to Christians as the twelve tribes, James was referring
to natural Jews and Gentile Christian. He was redefining what it mean
to be a descendent I Abraham.

James 1:2. "count it all joy when you face various kinds of trials".
James is saying that God's love will have the last word despite all
the bad things that can happen. Whenever you face crushing
cirumstances, remember that God loves you. [MRL note: I don't quite
see how to extract all that from this verse. He connects it to the
word Chara somehow.]

James 1:3. "testing of your trust" He's also saying to think it
through, and really understand the love of God. J is saying to ask the
tough question.

"Perseverence" means "you will make it" even though it's really tough.
We're not called to live in a party, as if nothing bothers us.

James 1:4. "let perseverance do its conplete world" Character,
clarity, understanding of who you are, emotional intelligence grows.

You learn that God's love, Shalom enables you to endure anything.

Example: 1960s killing of girls in Alabama. The parents are haunted by
the pain, and God's love was helping them to make it.

It's unrealistic to pretend to be happy. It's ok to actually feel the
pain.

------

Note from Robert S: David Jeremiah is preaching on James and brings a
different perspective.

Note from (unknown student): there aren't any tiny nuggets for living
that you can just get and have an easy time of it.

Sunday, April 19, 2009

"The Shack" Sermon Series: "The Invitation"

George Fuller is teaching a series related to the book, "The Shack". These are notes on his first sermon in that series, "The Invitation".

GF's views:

GF purpose: to change our relationship with God; to be more secure in God's love.

Sometimes the love of God surprises us. But we should progress so that we anticipate the invitation, and aren't so surprised.

Genesis 12:1-3 -- The call of Abram. God was calling Abram out of polytheism. Unlike the Shack which is fictional, this call of Abram really happened.

Exodus 3:1-8 -- The call of Moses.
This had to be surprising to Moses. This encounter changed everything.

1 Kings 19:11-14 -- God speaking to Elijah throug the gentle whisper. Elijah hears something that lets him reject his culture and stand for God.

John 12:23-33 -- Jesus announcing he will be crucified.

It may be "irrational" to thing Jesus lived and died and was risen. And it is irrational, but it's true.

We must go to a "place" we can find God and be really Real -- where we can be saved, be taught.

We have to learn to be relational, rather than trying to win arguments with rationality.

If you have ears to hear, and a desire to know, the accept the invitation of the gospel.

For Mack in the story, the invitation was to the shack. But for us right now, God is always here inviting us.

-- End GF views

Tuesday, April 07, 2009

Cables and Data analysis projects

When I was a kid, I realized I really liked cables. My first real
memory was when my Dad was hooking up the TV, VCR, and our TI-99-4a
computer, and the areal TV antenna -- I realized that the cables were
different, and had to be hooked up in a specific way. Some of them
carried signal, and others carried power. And, in general, they
carried their good stuff in one direction only. I guess I was 5 or 6
years old.

I still like cables. They just make sense. When I teach classes to IP
network technicians, I often recommend that each cable should get its
own identity -- a name like "C1", "C52", etc. Cables are people too,
after all.

But second to connecting cables, I've found another type of task I
really like: data correlation and retrieval. I'm working on a project
right now where I'm collecting data from a BroadWorks TimesTen
(Oracle) database, some log files with SIP that I have to parse, and
the database in an Acme Packet Session Border Controller (SBC). If all
this data were in one database, you could run a big query and get it
all out. But it's not in one big database, and it might not be worth
putting into one database. So I build custom data-access tools to get
it out. Hi, I'm Mark, your report builder.

It's reasonable to ask whether it makes sense to load this data into
one big database to allow general-purpose searching with a better
query language. There are a few downsides: the need to setup a DBMS
(like MySQL), and the need to parse the data to get it into the
database in a clean way. I can get by with cheap-and-dirty parsing via
regex; to load the data into a database I'd have to slice apart the
data in the log files to put it in meaningful fields. For example, if
I don't parse the SIP message before I put it into the database, then
I'd just be doing full text searches on the SIP messages. I'm not
completely convinced either way here.

In one sense, it's just work -- dump data out, do searches, etc. But
in this kind of project, nobody cares if I use shell scripts, or Perl,
or a "real programming language" to handle it. My vocabulary is
normally awk, grep, sed, cut, tr, bash, perl, head, tail, gawk. Nobody
complains at me for it being inefficient. If I get the information
out, that's all they care about. And nobody else I know likes to do
this kind of project, so it's a sort of niche.

Cables have something in common with data analysis and correlation.
With cables, you have two endpoints connected to each other by some
common medium. With data analysis, you can glue data together using
common (correlating) keys. Yeah, the query language is complicated.