Gerhard's Blog

Pleasing Developers

2010-05-29T11:10:00.000-07:00

Just read an article by Alex Handy on the cover of the June 1, 2010 SD Times "For APIs, pleasing developers is key to successful evolution". Sounds like, well, duh, but the article still has some good whys. Some takeaways: a) APIs are important and have to be maintained, b) developers want straight forward calls (REST), c) developers want stable APIs so their apps don't break, d) developer favor working code examples over documentation. Nothing radical there.

But it got me to thinking. There is a separation of concerns here. The folks producing web APIs typically have data that they are experts on. They want people to use their data, but the data experts can't be experts on all possible user communities. That's where the API comes in to separate the concerns. The data owner provides an data centric API and the developers who know individual user communities make the data useful to that community. No wonder it's such a powerful model.

2010-01-16T08:53:00.000-08:00

Good article on the importance of people over process.
Characterizing people as non-linear, first-order components in software development

Naval Analogies

2009-07-02T12:53:00.001-07:00

“Software Development” is like navigating upriver with a 20 year old chart – you have a general idea where you are going, but never know when you will run around on an uncharted shoal.

“Mere matter of implementation” is like the rocky jetties at the harbor entrance – they can still sink the boat, but most crews should be able to easily avoid them. Brought up when the real topic of discussion is whether you’ve actually found a safe harbor.

Code as Design

2009-05-19T10:36:00.000-07:00

A colleague of mine referred me to the notion of Emergent Design as discussed by Neal Ford. Part of Emergent Design is Code = Design. This reminded my of the elegant essays by Jack W. Reeves.

In both cases the argument is the same: code is the final manifestation of the design process. You don't "build code" to a design - the code is the design. You then take your design through a build process (compilation) to get an actual useful product (executable code). So you don't complete the design process until your code has been completed. It really explains a lot about software development and is a core belief of mine.

Debunking Cyclomatic Complexity

2009-04-08T05:37:00.000-07:00

Great article by Andrew Binstock. Basically they did a survey that showed for the majority of modern code, the McCabe Cyclomatic Complexity Number does not tell you anything useful about the probability of defects. Basically, the number has to be greater than 25 to predict defects but must code is below 25 and from 1-25 the survey found no correlation between the number and the defect count.

Component Testing

2009-01-24T06:14:00.000-08:00

The January 2009 issue of Software Test & Performance has an article on Better Quality Through Software Reuse. The author recommends a reusable component size of 700-800 lines of code with about 3,000 lines of test code. Then you need to document the component both for the application designers who need to understand when to use the component and for coders who need to know component details. Then off to white-box and black-box testing. So while reusable components are a great idea, they take considerably more work to create initially...

Tried Maven for Jibs

2008-10-28T04:56:00.000-07:00

Over the last few days, I converted JIBS directory structure to work with Maven and got Maven to build JIBS. JIBS uses a three other jar files so I really like Maven's repsoitory. Unfortunately, none of the jar files I use are in the Maven repository.

So far so good. Based on my experience, if you are doing lots of smaller Java projects that need to roll up to a big deliverable in an orderly way, Maven is great.

I was particularly impressed with the strongly recommended directory structure (convention over configuration). Moving the files around not only made Maven work out of the box, but made the project more understandable and simplified my existing Ant scripts. Clearly an advantage if you are working on many projects since they will all have the same basic structure.

So, to recap, the good points were:
a) Maven does way more than Ant for its size
b) The dependency management features are great
c) The self-documentation features are great

But I won't be replacing my Ant scripts with Maven. Problem is that on the same code base, I compile for both Java 1.6 and Java 1.4. I do this by dropping a few source files and then calling the compiler with a 1.4 compile option. Opps, no readily apparent easy way to do this in Maven. (I'm not sure there is any practical way to do this in Maven.) Also, I unzip jar files and include classes in my distributable - making it a one click jar file (with an exe wrapper). Again, that's not a Maven kinda thing. So, I'll just stick with ant as my main build tool for the moment.

So here are the bad points:
a) You fall of the face of the earth very very fast if your project deviates from Maven's model.
b) The documentation is a bit sparse.

So, in poking around, it looks like Gradle could be good, but my Ant scripts are working just fine for now.

What do I suggest?
a) We adopt the Maven directory structure
b) We use Maven or other dependence management tool to manage all our modules/products/projects or whatever the heck we call them.
c) We use Maven for when its good (enforcing the directory structure at least...)
d) We use something else for when its bad

Gerhard

Gradle
Ivy
Ivy Review

Maven Issues #1
Maven Issues #2
Maven Issues #3

The Agony of Java Preferences

2008-10-19T08:06:00.000-07:00

My open source project, JIBS, uses Java preferences to save user settings. That part works very well using the Windows registry or, for Linux, hidden directories on the user's home. So far so good.

Then I have a user who says he want to use JIBS with his data on a thumbdrive as he moves from machine to machine. Well, OK, all I have to do is figure out how to write the property files out and read them back in without going to default registry and leaving garbage on every machine he visits.

So I extend Preferences and use the export function to get the file out. A quick test show that the import function reads it back in nicely. What I didn't notice on the quick test is that the export is a non-static function (meaning it works with my extension great), but the import is a static function (meaning it ignores my extension and write to the system properties - which I am trying to avoid). Argh! The lack of symmetry alone is enough to drive you crazy.

Next up, the preferences can not be changed while a program is running - you have to pass in on the command line. So if I try to use a pseudo preferences, I can write them out but not read them in, and if I use the real preferences, I have to have the user's type them on a command line. Yuck.

So now I have a starter module the forms the correct command line then cranks off another instance of Java. Seems a little silly really. Then I notice I lose all console statement (useful for debugging). So I have to get console output of the second Java instance and print it in the first Java instance and create a single from the second to the first so they will both shut down together.

Got all that working and fired off version 2.3.1. Then I hear from another user that JIBS won't work if he moves it from his download directory. Turns out I tested on paths with no spaces and he moved it to directory with spaces in the paths. So after a bucket of double-quotes I finally fixed that problem.

And all this after my first quick look way "no problem, I see preferences has both export and import"!

Don't Make Me Think

2008-10-19T08:00:00.000-07:00

Steve Krug's nice thin "common sense approach to web usability".

Very practical book of good web site design techniques. Two things basically: follow conventions so user's easily know what to do with your site and rigorous but simple, easy and cheap testing. One of the points is that if the testing is not simple, easy and cheap it won't be rigorous because to be rigorous you need to do it early and often. Good points of no such thing as "average user" ect. Excellent read altogether.

The Inmates are Running the Asylum

2008-10-19T07:53:00.000-07:00

Finally got around to reading Alan Cooper's "The Inmates are Running the Asylum". Alan Cooper is the father of Visual Basic and an outspoken proponent of making software easier to use. This 1999 book is still relevant today - it basically proposes the need for interaction design using very specific personas for the users and focusing on their goals.

37,400

2008-09-04T12:25:00.000-07:00

From Good Old Advice by Dr. Alistar Cockburn:

One Process Will Not Fit All

People in our field search continually for the one, true process which, if we could only find it, would serve as the base for every project and also as master training material for newcomers to the field.

In [21], I investigated this question directly. I discovered that processes must change as technologies change, and also change to fit varied types of projects. How many types of projects are there? Capers Jones estimated there to be at least 37,400 different categories of projects [7]. No wonder no single methodology or process will fit them all. Do not believe in any single process or methodology because each works only in a particular and limited context.

[7] Jones, Capers. Software Assessments, Benchmarks and Best Practices. Addison-Wesley, 2000.
[21] Cockburn, A. "People and Methodologies in Software Development." Diss. University of Oslo, 2003 .

37,400 different project types!! Yeah, no one wonder one size fits all solutions don't work!

People > Process

2008-08-24T16:40:00.000-07:00

We all know from the Agile Manifesto that it is more important to value Individuals and interactions over processes and tools. This was brought out again for me in this month's issue of CrossTalk, the Journal of Defense Software Engineering. This was CrossTalk's 20th anniversary and they decided to have some retrospective articles. The very first was an article by Watts Humphery, the father of CMMI. In the Process Revolution you get the story of the CMMI and a pitch for how great process is. The next article is Good Old Advice by Dr. Alistar Cockburn. This is a basic "it's the people stupid" article working the evolution of the agile manifesto all the way back to the waterfall method! (No kidding, there a waterfall in even in Scrum...) Paul Kimmerly's Heroes: Carrying a Double-Edged Sword gives another perspective on "it's the people stupid". In What Have 20 Years Accomplished and What Is Left to Accomplish in the Next 20 Years? Gerald M. Weinberg provides some interesting ruminations.