Summary
It's been long enough and I don't seem to be much better off following the advice of these guys.
Advertisement
I got to work the other day and an email was in my inbox. It came from someone in the field in the process of getting our system deployed at a customers site. Here's the bit that struck me most (reposted with permission). It's a little long but worth reading I think:
Every day the applications lead and the claims lead spend a couple hours
going through every transaction entered the day before, reading through
917-byte records to identify the cause of any upload errors. Tensions
are high. Nerves are fraying.
Transaction upload testing is probably the last major hurdle we face
before going live. To get an appreciation for what this is like, here's
one example. Imagine a Reserve event fires and hands you a $500
reserve decrease. This one event has to be handled in one of several
different ways, depending on what fired the event and what else has
happened on the claim..
* If it was automatically generated along with a final payment
transaction, you have to throw it away and not give it to the mainframe.
* If it leaves open reserves behind, you send an RC transaction
with two amounts: the PAID-RESV-AMOUNT is the amount of the new open
reserves, and the ORIGINAL-RESERVE is the amount of the change (yes,
that's completely counter-intuitive). Since the amount of the change is
negative, you have to send the following string, which means -$500:
"0000005000}" (that last brace is part of the string and means that the
last digit is zero, and the sign is negative; there are nine other
symbols for the other nine digits).
* If it leaves no open reserves behind, and there have been
payments made on this reserve line , you send a CL transaction, with
the amount 0.
* If it leaves no open reserves behind, but there never were any
payments on this reserve line , you send an NC transaction, with an
amount of 0.
Oh, and all of that only applies to indemnity payments; for other cost
types, the rules are different (luckily, they are simpler). And all of
that only covers 22 bytes out of a 917-byte record. (They're not all as
hard as those 22.) And you have to protect it in front with a battery
of transaction validation rules to prevent the user from entering a
transaction that will break the upload - like changing a reserve twice
in one day (but a new reserve and a change are OK), or entering a final
payment the same day as a reserve change.
Then imagine that the client gave you incomplete requirements in the
data mapping several months ago, and you don't find that out until your
917-byte fixed-width record errors out on the mainframe upload, and the
only way to find out the right requirements is to look at the records
that the current claims system is producing.
My initial reaction was to be sort of offended. I mean really, who built such a thing? Mustn't they be embarrassed? A little while later I got over myself and started to think a little more rationally. I realized that it doesn't matter. This is the reality of the world I live in. In some small way I even helped create it. It's a filthy place, filled with exceptions, caveats and halfways.
When I got home I started looking at my bookshelf. It's filled with books on how to write software. Old stuff from Yourdon, some Booch, Fowler, GoF and lots more. I came to the conclusion that these books were written in or for a world that doesn't really exist. To be sure they help me strive for a less disgusting place to live. But they don't spend a lot of time talking about my house, metaphorically speaking.
I think that those who propose to set out to tell me how to develop systems actually live someplace else. Periodically they drop in, they show me some pretty pictures about someplace over the hill that I've only imagined and hoped for. And I look wistfully at those pictures, and listen to their arguments. If I'm chaste enough, if only I have discipline and faith, I too will enter this wonderful place where things always moving forward, where systems flow with the consistency of oil, and everyone is dedicated to the crafting of something right and beautiful.
I think it's a myth. I think I'm very, very far from this place. I think I'm going to stop listening to these guys. I think I'm going to start looking for people who live in my world, who tell me how they slay their dragons and hope I can use what I learn to help slay mine.
"I think I'm going to start looking for people who live in my world, who tell me how they slay their dragons and hope I can use what I learn to help slay mine. "
I think you're on to something. <p/>
What dragons? What do you want authors to tell you?
I think the thought leaders tell you about dealing with incidental complexity, not domain complexity. By incidental complexity, I mean complexity as a result of the implementation, which is a byproduct of the design decisions that are made.
When the domain changes or is difficult to define, I don't know if there is anyone who can particularly help with that.
> I think the thought leaders tell you about dealing with > incidental complexity, not domain complexity. By > incidental complexity, I mean complexity as a result of > the implementation, which is a byproduct of the design > decisions that are made. > > When the domain changes or is difficult to define, I don't > know if there is anyone who can particularly help with > that.
I think authors tell about neither, or at least I'm coming to believe that. I suspect the problem is that there is little humanity in the design process as described by many folks. Not too much talks about how to deal with code written by, say, a less experienced developer that you discover late in the cycle and want to fix.
I have a specific example of this I'll try to write up in a few days or so.
> "I think I'm going to start looking for people who live in > my world, who tell me how they slay their dragons and hope > I can use what I learn to help slay mine. " > > I think you're on to something. <p/> > > What dragons? What do you want authors to tell you?
I'm not entirely sure. I think I'm going to start cataloging the problems I run into and writing those up. However I think most of them have to do with the lack of consistency of humans, dealing with a lack of discipline in team members and yourself that causes kruft accretion, loss of intention when people add on to code you've written and vice versa. Things like that. Put another way, and I'm getting really stuck on this theme, there is a lack of humanity in what I've been reading. Perhaps I want a developer physchology book.
I think you've hit the nail on the head when you talk about the people problems. I don't think there's actually much wrong with the thought leaders per se except that they focus much more on software than on fleshware.
I'm currently working on back office system integration - a financial processing system that has some of the characteristics you describe - and I'm able to apply OO design patterns to the integration code I'm designing and building but I can't control all of the weirdness of the data formats. Using the best practices available in terms of design I am, however, at least able to build some software I'm proud of and which is proving very robust in the face of constantly evolving requirements - just as with your system, we're finding that even after months of requirements discovery and analysis, there's just a lot of legacy stuff in the old system that no one remembered (or perhaps never even knew about).
The world of legacy systems - which is the "real world" for the vast majority of us - is a much harder place to discover, learn and apply the best practices advocated by the thought leaders. In order to advocate that stuff, they pretty much have to confine themselves to the world of green field projects - otherwise they'd get bogged down in details that relate to the legacy and not to the new thoughts.
So don't be too hard on them until you've tried to walk a mile or two in their shoes (and always try to catch them at conferences where you can ask them in person how to apply what they're saying to a legacy project like yours!).
> > I think the thought leaders tell you about dealing with > > incidental complexity, not domain complexity. > > I think authors tell about neither, or at least > I'm coming to believe that.
And just to offer a third point of view, I actually think that the "thought leaders" talk about dealing with essential difficulty. Here's a set of requirements and a blank screen - now build the system. The average developer spends lots of time dealing with accidental difficulties: inadequate tools, bad legacy code, pointy-haired bosses, etc.
We all know how frustrating it can get. But it doesn't have to be that way. Not all the time. Rick, would you keep a weblog about your job if you didn't love it? Would you love it if it was like that every day?
I know I've been working with good teams, good tools and a good codebase. The essential difficulties were still there, and I was glad that I had my little bag of tricks with me - some of them courtesy of this or that thought leader.
It seems to me that thought leaders *are* thought leaders because they *have* lived, and still *do* live, in the messy world of real software; and want to change that world. So they hold up a standard. They say: "Look, everyone. It doesn't have to be the way it is! It *could* be *this* way!"
Is that reality? Yes! Or at least it *could* be. More than that, it *should* be.
We know how to write clean code. We know how to design clean systems. We know how to write intentional expressive software. We know.
What we must do is educate, educate, educate. We must teach those who don't know how, how. We must teach those who don't care, to care. We must teach those who won't care, to get out.
Yes, it's messy. Yes, it's dirty. Yes, it's a long long row to hoe. So what? If you want things to get better, you have to start where you are and put your efforts towards it. You have to envision the kind of profession you want to work in and then drive as hard as you can to make that profession a reality. If you give up, you become part of the problem -- one of those who stopped caring.
> I suspect the problem is that there is > little humanity in the design process as described by many > folks. Not too much talks about how to deal with code > written by, say, a less experienced developer that you > discover late in the cycle and want to fix.
Have you read any of Michael Feather's manuscript in progress: "Working Effectively with Legacy Code"? You can find it on: http://groups.yahoo.com/group/welc/
As for "humanity" it seems to me that the entire thrust of the Agile movement is humanistic. It's about how to get real people to write great code.
> I'm not entirely sure. I think I'm going to start > cataloging the problems I run into and writing those up.
This is a good idea. I think you should do that. Some folks might be helped by it. Perhaps it would make things a little better.
> However I think most of them have to do with the lack of > consistency of humans, dealing with a lack of discipline > in team members and yourself that causes kruft accretion, > loss of intention when people add on to code you've > written and vice versa. Things like that.
Tough problems. Thought leaders (your term) preach to the choir, and the choir isn't the problem. One hopes that the choir will walk out into the pews and talk one on one with those who need the most help. To reach the congregation you've got to get the choir singing.
> Put another way, > and I'm getting really stuck on this theme, there is a > lack of humanity in what I've been reading. Perhaps I want > a developer physchology book.
Have you read Software Craftsmanship by McBreen? Have you read Peopleware? Slack? The Deadline? by DeMarco, or The Mythical Man Month by Brooks? These are all about the human issues.
Yes, "thought leaders" mostly write about an idealistic situation. Just as the textbook examples about programming are idealistic examples. Real examples would most of the time just be too complex. They would hide the point I want to bring across in a pile of details. So to bring my point across, I have to leave out most of the messy real world details.
The interesting thing is that people are capable to transfer the idealistic situation they read about to their real world situation. It does take some time and practice. It's not always that easy, but it works quite often. I have gathered a lot of good ideas from the "thought leaders". It's not always as easy to apply them, of course. I don't always succeed, but I'm getting better, every time I try.
And people do learn programming from programming textbooks, too. It only really works if you combine it with practice, of course.
But in addition to the idealistic writings, some reports about real life projects would be interesting, too.
I stopped listening a long time ago. I swallowed the C++ party line of type safety, const correctness, the importance of peak runtime performance, etc.
I preached the gospel of UML, specification, design artifacts, rigorous analysis, and the rest of it. I made money providing Methodology (note the capital M) coaching cash laden clients in RUP, Spiral, Catalysis, and some others.
Since then I've concluded that this stage of my life was much too cluttered with dogma and ideals that didn't work too well in practice. Vast investments in process and straight jacket languages with nannying compilers (yes Java - you too) just added significantly to my cognitive load without adding real value.
Now I prefer to develop in dynamically typed languages with more expressive freedom (Smalltalk or Objective C typically) and I work using the babysteps methodology (my name for XP - think of something good to do - do it - think of something else good to do - do it - lather rinse repeat).
Dogma I don't need and I don't give a fig for compiler enforced anything.
Flat View: This topic has 37 replies
on 3 pages
[
123
|
»
]
Previous Topic
