Clever is not smart

Posted by steve | Smalltalk | Saturday 29 August 2009 10:39 am

This is going to be a small rant. Before I begin I should set a context. I’ve been programming computers now for more than 30 years. And I’ve had the good fortune to have paying jobs doing Object Oriented Programming (OOP) in Smalltalk for over 20 of those years. I enjoy this work very much.

Furthermore, my experiences in programming has been relatively broad in that I have worked on financial applications, insurance applications, development utilities, industrial process controls, point-of-sale kiosk software, Virtual Machine-level troubleshooting, entertainment software and applications delivered in multiple human languages. Once even in Kanji, but I can not read a work of Kanji. I’ve also conducted workshops and seminars, provided many mentoring and tutoring sessions, and have worked as an Adjunct Professor teaching programming skills.

But this is not going to be a rant about “How we used to do things.” I’ve noticed as I work with teams developing software there are a few common problems and behaviors encountered regularly.

Knowing that I have an “astigmatism” because of my deep involvement in the Smalltalk community, I have a tendency to view many aspects of programming through the lens of an Object Oriented Programming developer. I see things in a very Smalltalk-centric way and I’m discussing things seen on Smalltalk projects. However, I’m guessing there is a level of universality.

Complex problems to model
It doesn’t matter if we are talking about financial settlement models, high speed process control systems, high speed transaction systems, insurance billing models, serving up reports over the web or whatever. These are complex systems. These problem domains are often loosely defined and changing throughout the development cycle. Complex problem domains often include nuances and subtlety seldom encountered in everyday programming projects.

Smalltalk is used to handle complex problems
Smalltalk is often used to handle complex problems because it can do it so well. Smalltalk makes modeling complex systems simple. For both Object Oriented Programming and Smalltalk, I can say that I have never worked with a more productive environment that allows programmers to tackle difficult problems with rapid reliable results.

Handling the complex well is one of Smalltalk’s strengths. And here’s the really cool part. Smalltalk syntax is dead simple and easy to read.

While it’s true it may take years to acquire the skills of a more seasoned Smalltalk developer, folks with a decent amount of Smalltalk literacy (and I’m talking about what you can learn in a weekend) can make meaningful contributions to a team project even as newbies with proper coaching and mentoring available.

That’s the beauty of Smalltalk. It provides a rapid reliable development environment for complex problems in a an approachable manner. Smalltalk is not “file-centric” like some of the so-called modern programming languages, so that takes a little getting used to. You do almost everything inside code browsers, inspectors and even develop within the debuggers. The language itself is easy to learn.

The class library of Smalltalk, refined and developed for over 30 years, is both rich with capability and daunting to approach for a new-commer. You could probably make that statement about any rich library of information, even those outside of programming. The skills required are learning how to look for things, how to recognize their value and where and when to apply what you know. But you also can start out doing quite powerful things after grasping just a few key core Classes in the library.

Complex code
It also evident that complex models are created to solve complex problems. Keep this in mind. Smalltalk helps to make the complex easier to express and model. Smalltalk code can be very simple to read and understand.

That’s not the same thing as saying you can write code without careful thought and study. Remember we are modeling complex problems with powerful software.

In addition to good Object Oriented Programming concepts, most Smalltalk development teams use SUnit. This is the testing framework behind the modern concepts of Test Driven Development (TDD). It’s roots began in Smalltalk and are often integrated into the everyday development processes the Smalltalk teams use to deliver quality code.

I’ve become a strong advocate of this approach, recognizing it’s strength’s and weaknesses, and consider TDD an essential component for delivery of quality code.

Development team composition
Modern software development teams are not composed from a full compliment of strictly seasoned programming veterans. In fact, it’s been my experience that teams with limited diversity in experience are often the worse performing. A full team of “Type-A” individuals will have a high level of both churn and drama. A good team has a mix of high-end talent, less experienced programmers, and developers with good business domain skills. It works just fine if the domain experts also have the least Smalltalk programming skills. Over time domain knowledge and programming knowledge will grow for the entire team.

Usually the more seasoned the developer, the lighter and cleaner the code is. A seasoned developer will write less code and often deletes code. I know, that seems contradictory.

Learning Smalltalk
It takes very little time to learn how to develop in Smalltalk and become a contributing member of the team. It takes a little more time to develop decent Smalltalk literacy skills, where the developer can browse code and quickly understand what is really going on across multiple collaborating objects. It can take quite a while before the developer begins to leverage well the deep Class library of code available.

A problem occurs when Smalltalk developers without strong code literacy skills (reading and comprehension) are writing enhancements for or fixing bugs in existing code. They often don’t catch the nuances in the code. But it’s often not their fault.

Let me draw out an example or two.

Example 1. The relatively new developer correctly determines that the root cause for a problem is code that exists in a common super-class. So he or she begins to modify code in the super class without really noticing how the other subclasses use it. Things could break. Hopefully the team has constructed a strong suite of SUnit Tests that will catch if a programmer inadvertently breaks something in this manner. But it can be difficult to detect.

The developer should apply code refactoring to break out unique behavior amongst the subclasses. A new developer should not be expected to have those refactoring skills. That takes time and training. Mentoring or “just-in-time” pairing helps.

Example 2. Smalltalk is a “late-binding” environment. That is, the “type” of an object is often irrelevant if it is passed as an argument along with a message. The receiving object will handle whatever it gets. Sometimes a developer will attempt to simplify method arguments so they are always assumed to be of one specific kind. Sometimes this is done to an extreme level. For example, an Array object is a kind of Collection object. You can ascertain it’s size (dimension) and you can access it’s components by iterating over it with indexes. However an Array object is a fixed size. An OrderedCollection has many of these same properties, also inheriting from the Collection class hierarchy, but you can change it’s size by adding and removing items. If the developer starts writing code assuming the argument is always an Array, a consumer of this method may discover they can no longer use it’s service for a more flexible Collection type. It breaks.

The developer should examine the known senders of the message and see how it is used. Also, it’s almost always the case that correct behavior in a method allows for the more general object to be accepted as an argument. New developers often don’t realize the subtlety and power that comes from polymorphism.

Example 3. We are often taught that comments in code are a good thing. Certainly throughout our school years we’ve probably even gotten feedback that not enough clear comments exists in our code.

I tend to take the opposite view. A comment is a sign that something hard to understand is happening in the code. The correct approach, in my opinion, is that the code should be made self evident. Add a comment if you need to alert the developer to something, but do it sparingly. Comments never tell the computer what to do. A comment is a note to a human being.

Time out for a humorous story.

A Computer Science student with excellent skills and grades volunteers to help out at the computer lab at school as a lab assistant to help newer programming students work on their assignments. One day a very frustrated student approaches the lab assistant with computer printouts in hand and, exasperated, exclaims that he just cannot get the program to work. The lab assistant begins to pour over the program listing. While examining the code, the new programming student exclaims, as a way of demonstrating how frustrated he is, “I get the idea that the compiler is ignoring all my comments.”

Comments never tell the computer what to do. The programming statements do. So why am I writing about this? When I find code that has a lot of comments in it I get curious and begin to review it for possible flaws in the logic. The programmer obviously thought it was difficult to write and understand. It’s a tip-off for me. I once even saw a comment that said “I pray to God this works.”

Oh yeah. That will work. A new kind of development model: Divine Intervention Development (DID).

Other team factors
Our industry is also loaded with egos. That’s easy to understand. It often takes an exceptional mind to break down the complexities of the real world and model them in manageable software. Math Majors and Engineers often make great programmers. Our industry tends to collect individuals who really think about things. We call ourselves “Analysts” for good reason. And it’s also easy to see that programmers can have both a narrow approach to things and how they see the world.

The problem with this is that it can show up in the code in ways it shouldn’t. How many times have you seen a piece of code and you say “That’s brilliant”? The cool part is when you realize the brilliant code is often also dead simple.

Cleverly written code
Yet we also encounter code everyday where the programmer was just being “clever”. I have nothing against clever programming. But here’s the trick.

The code has to be “smart” and simple. If you are doing some trick in the code because of a technique you’ve seen elsewhere, stop and think about this for a moment. What kind of team do you have? If you have a lot of newbies on the team, it could be an un-smart choice.

Keep things simple. Make it obvious what you are doing. Rarely do we really write code that has to be constructed as if we were writing in “C” or Assembler. Make the flow of the algorithm obvious, perhaps even including temporary variables in intermediate steps. Don’t waste everyone’s time writing highly optimized, fast, code. Write maintainable code. Write something that can be read quickly and understood immediately.

Set the example
Training takes time. If you are an experienced developer, remember that the new coders are likely going to be browsing your code and reusing it. Often, that’s actually where some of the brittleness comes in our projects. Rather than reading the code to understand exactly why it is written the way it is, a new coder will often journey on a “cut-and-paste” raid, grabbing pieces from anywhere to make something work.

That’s okay as a first pass at a solution. But take the time to go back and revisit these situations. You probably have an excellent opportunity to refactor code and probably redesign. If behavior is being replicated in multiple places throughout your project, manifest as little repeating snippets of code, that’s a sure sign there are one or more objects missing from your design. Search for these gems and see if you can remove code by elevating the behavior to a richer object.

And don’t shy away from using First Class objects. We’re not coding in “C” here and passing around lots of strings as arguments. If you have a first class object that has powerful behavior, use it.

Strong unit tests
Another area that takes real time to develop skills, is in understanding how to write unit tests with good code coverage. What I’m looking for is a test suite that exercises the model in as many permutations as you can imagine. Yeah, that’s often tedious work. But it protects you from later damage done by someone, including you, fixing a problem without realizing it’s impact on other parts of the system. If there are combinations of inputs that can exercise a set of Boolean logic in your model, construct a “truth table” of inputs and outputs for those combinations and codify it in a unit test. Lock the behavior of your objects down.

Refactor by design
I’m making a case here for building-in a level of expected refactoring in code and design. We’re all human and our knowledge about a domain evolves over time as we learn more about it. This is often the root to some of the “change” that can be so difficult for programming teams to adopt. The team may institute a change. The customer may request a change. Accept this as a natural effect of how our knowledge grows. Changes in requirements are actually a good thing. Changes can cause you to revisit your assumptions and realize how to make a richer more flexible model. You shouldn’t be expected to be aware of all ending conditions when you start a project and neither should your customer.

Tactical and strategic responses to issues
There is one down side to rapid response that I have seen that troubles me. I know, you may be wondering how rapid response of any kind may be bad. This shows up in at least a few forms I can think of while writing this.

Don’t strictly reward quickly fixing bugs. Sure, we want bugs fixed quickly. But here’s the thing. If the development team becomes “trained” at quickly finding the errant code piece, correcting it and then shipping it, an opportunity is lost and a mistake is being made. We are rewarding the wrong behavior. Often bugs are universal. What was coded wrong somewhere was probably replicated elsewhere. Count on it. To some extent this shouldn’t actually happen. I believe the best projects are where code is never duplicated across classes. Write it in one place. Then if you find a bug you know you fixed it everywhere. Sometimes the bug was really just a change in the design. These are more subtle and difficult to find when they exist in other places in the code.

Smalltalk will help you
Smalltalk provides outstanding tools to assist you in finding similar code. Look for other implementors of the same method name. Look for similarly named methods. Look at senders of all of those methods. Learn to develop good browsing skills in your team. Reward finding similar bugs and eradicating them by reducing code first.

Also, when you find a bug, immediately begin thinking about how you can construct a unit test to demonstrate the bug exists before you even fix it. This way, after you fix it, it should never re-appear.

Software debt
If the team ignores the need to be vigilant about code refactoring, you will build “software debt”. These are places in the code where you know things are brittle, and given other conditions, will fail. Refactoring should be a natural built-in part of the development process. If you are developing in quick iterations, consider adding a short iteration where the team does nothing but refactor code.

I tend to follow the process that says, “Write it to work first, have strong unit tests to exercise it’s permutations, and then refactor before you are done.” That’s critical to refactoring. You need to have the faith that there are unit tests that will exercise the code you are refactoring. If not, you’re taking chances. Ensure the code is tested before you refactor it.

Remember what really matters
I was once part of a development team where the manager declared that the most important thing was that we deliver the software on time. There’s a nuance and perspective that I like to add to this point of view. I agree, never lose sight of who is paying the bills. After all, the first order of business must be to stay in business. You have to deliver and keep your promises. To a certain extent, that means you are obliged to only promise what you can deliver. That’s how you build trust – and not just in the software development world either. Delivering on your word is the universal technique for gaining trust.

Here’s another important consideration. Most teams are comprised of a mix of junior and senior developers working together. Obviously the skills of all will and need to grow. Software development is an expensive proposition, even when ignoring failed projects. Dollars spent, time spent, it all matters. And no one like to pay what it really costs to develop custom projects.

But if all you do is deliver a software product when you are done, you haven’t done enough. You should also be delivering a better quality development team.
The product should be finished, yes. But the team should be better as a result too.


Capture it in a unit test

Posted by steve | Smalltalk | Thursday 7 May 2009 4:15 pm

While discussing some released code recently with a colleague, I remembered a little “rule”.

We were talking with a customer who was giving us feedback about what appeared to be a bug. The developer looked up the related code and discovered comments in the code that described why it was done the way it was done. Essentially, the customer was reminded that it was working as previously requested.

However, this reminded me of an opinion I have about both comments in code and capturing requirements. I believe that comments in code are useless. There are exceptions of course. The problem with comments are that they aren’t part of the code stream and there’s nothing to control that they are correct. Comments can even be misleading.

Reminds me of that old joke of the lab assistant at college helping new programming students getting their assignments correct. The lab assistant was asked to help a student and that student remarked, “You know, I get the idea that the compiler is completely ignoring my comments.”

So what about the situation where the “reason” for some code was captured in comments?

My recommendation is to capture your requirements in a unit test. Get rid of the comment. Make a unit test that demonstrates the setup and expected results in such a clear manner that it’s obvious what the requirement was.


Progress on my GEDCOM publisher

Posted by steve | Smalltalk | Wednesday 22 April 2009 9:40 pm

For many years now I’ve had a Smalltalk tool written with Squeak that would process a standard genealogy GEDCOM file and create a suite of HTML pages. I’ve been meaning to write an editor for the actual genealogy data using Squeak but there’s always been some other project that wins in priority. I know, I know, I’m diverting attention from getting my Squeak Laser Game Tutorial book completed. But writing code is so much more fun.

As I had written here before, when I went to Cincinnati earlier this month I spent some time with my mother reviewing updates of information we had regarding my family tree. Well, that decided it for me. Rather than use some 3rd party tool to edit GEDCOM data I decided to write my own in Smalltalk. The basic presentation tool is working correctly. I still need to write the individual dialogs for each specific edit (individual, family, children), but that should turn out to be fun and worthwhile.

Here’s a screen shot of the current state of my editing tool.

GEDCOM Publisher editing tool in Squeak

GEDCOM Publisher editing tool in Squeak

The data is currently showing my mother, the spouses she has had, my father (the spouse I was named after), and her children from that family. For folks familiar with Squeak’s Morphic graphics, you can see that I did some custom work for the list panes used in this editor. I added column lines and list header lines.

That’s it. I just wanted to post a note about the work I’ve been doing on this personal project in Squeak.


Working on my Genealogy software

Posted by steve | Smalltalk | Tuesday 14 April 2009 4:25 am

While visiting with Mom last week in Cincinnati, we spent some time together reviewing the family history tree information we compiled 15 years ago. I made notes on corrections and additions needed to the database. She’s an amazing and rich resource for this information. There’s an amazing little side story I’ll have to write about someday that sheds some light on positive things that came from World War II in Germany, and about how remarkable my mother really is. Between the two of us we have accumulated quite a bit of information. I’ve received a number of E-mails over the years from people who have contacted me from reviewing the Wessels family tree published on the Internet. Some of that E-mail was written in German, which I cannot read, so I was glad to review all of those notes with her.

Most Genealogy software uses a standard file format called GEDCOM for sharing information. Back in 1994 I embarked on a Smalltalk project (in Squeak of course) to read, and write, GEDCOM file data. The most important part of that project, from a technical aspect, was to create a tool that wrote a full suite of HTML pages as output. The Wessels family history tree linked above is that output. The Squeak application reads in a GEDCOM file and produce static HTML pages which are then uploaded to our personal web site.

Writing an application like this in Smalltalk is very rewarding because I learned a lot about modeling family history information and it gave me the freedom to create the type of output reports that I really wanted. Of course, today, I would probably approach this as a Seaside application since creating these pages dynamically would yield interesting query and search capabilities. Seaside is of course one of those wonderful dynamic web frameworks written in Smalltalk that really exemplifies what can be done with managing dynamic information on the web. The trick for me in porting to Seaside would be in finding a web host where I can actually run the application. I’ve been using my current web host, Lunar Pages, for many years now and am quite satisfied with their reliability, capacity and cost. However, like many other web hosts, they support PHP, MySQL and Ruby, but alas no Seaside. Time to get more of these web hosts educated. Like most Smalltalk enthusiasts, we’re leading the curve on much of what becomes common place software concepts years later.

Going back and enhancing the Squeak software for this project after all these years was informative. There were only 2 bugs I found when porting to the latest version of Squeak 3.10.2. The bugs were related to how Date objects work now. The newer Month objects in 3.10.2 are a good design but caused a small hiccup in my application which I was able to quickly find and fix.

I have some ideas for enhancements and have begun coding those in earnest. I’ve also learned something about myself from reading through this code from years ago. There is clear evidence that indeed my coding and design skills have grown over time. For example, I was not using SUnit as heavily as I do nowadays. However, I had coded quite a few testing methods as Class methods used to validate the implementation. It was simple enough to extract those into new Test Case classes for SUnit. I also saw quite a few opportunities for refactoring. There was a lot more repeated code chunks in that code than I would have written today. As I’m sure any experienced developer already knows, you find refactoring opportunities as soon as you add enhancements to legacy code.

I’m still writing my next update to the code and will also update the family tree data when it’s all done. That should be in about a week. As an additional exercise I’ll look into what it would take to host this all as a Seaside application too. The best way to really learn about Seaside (or anything else for that matter) is by just doing it.


Programmable programming languages

Posted by steve | Smalltalk | Tuesday 7 April 2009 7:40 am

Just read an article about LISP where the author mentions “programmable programming languages”. I love meta programming too. I first learned LISP 20 years ago at the urgings of my friend Larry Hollingshead. He’s the one who introduced me to Smalltalk back then too.

The comment about meta-programming reminds me of a quote I once heard that Alan Kay had said about Smalltalk programming. “How come no one ever subclasses Class?”

That’s what I love about the Smalltalk community. Programming about programming is fun.

Long live the “Meta Object”.


Smalltalk Debugging: You’re not done when all you do is fix it

Posted by steve | Smalltalk | Saturday 4 April 2009 9:34 am

Here’s a scenario you may recognize. The product your team has been diligently making progress on has a few discovered bugs. A developer agrees to fix one of these bugs. The classic technique that Smalltalk developers often adopt is to setup an environment reproducing the bug, set a breakpoint someplace useful, and run the code. Sure enough, when the breakpoint is hit the developer “walks into” the bug by single-stepping and inspecting intermediate results along the way. The flaw in the code’s logic becomes evident and the program is modified, often right there while inside the debugger. The fixed code is then published into the product’s source repository. Good investigative work, with a quick fix. Move on.

However, if all you do is fix the immediate bug you really haven’t done the whole job. Here are some ideas to consider.

1. I’m an advocate of Test Driven Development. If you’re not doing that then at least have a rich suite of unit tests using SUnit to qualify the code in your product. The responsibility you have as a developer following a unit-test covenant is that you need to create a new unit test demonstrating the code was broken before you fixed it. That means you back your fix out, putting the code back into its broken state. Then you write a new unit test case that exposes the defect. Finally, put your code fix back in and let the new unit test validate it is now working correctly. Another reason you should create unit tests to clarify the logic your bug fix repaired, is that this is a “defensive maneuver.” When you add unit tests, enriching the test coverage over your code, you also protect yourself from a later code change inadvertently breaking things again. When you find a bug, write a test case that exposes it. Then fix it.

2. Does the bug you found exist anywhere else in the code? For example, it’s common behavior for inexperienced developers, when writing, to browse for similar patterns and copy code as the basis for their solution. So you end up with little snippets of code repeated all over the place. In some cases they’re not little snippets. Fortunately, Smalltalk does an excellent job of making it easy for you to find these implementors and senders of methods, and find repeated patterns. Take the time to look for them. Sometimes the method has “neighbors” with similar names. Browse those guys to see if the code is the same there too.

3. Finding the same code pattern in more than one place is also a tip that you have an opportunity. I go by the philosophy that small algorithms should never be repeated in the code. “Copy-Pasted Coding Raids” leads to software debt, increasing your overall software maintenance costs. Find all those common places and refactor to reduce how often the code is repeated.

3. Refactoring is another hallmark of quality software development. When you find common behavior coded in several places in your product, consider that maybe you missed an object in your design. Go back and think about it. There’s probably a new object you can create that exhibits this common behavior and then use that object in all those places.

4. Related to design refactoring, you can look for methods that have way too many arguments. I refer to these as “passing a whole paragraph around.” Refactor that mess and create an object. You’ll probably discover that some of the behavior implemented on the consumer method really belonged in your new object.

5. Sometimes, the bug fix is more than just a simple change to the code. Sometimes you end up writing several lines of code to enhance or correct a flaw in the logic. After you get things working, go back and reflect on the design. For example, if your product uses models and persistence layers to describe and manage your objects and you have a properly separated presentation layer, if the bug was in presentation layer code; maybe the behavior belongs in a model somewhere? In other words, if you added lines of code to the methods that change output on a web page, that’s probably a tip that the behavior is implemented in the wrong place. The presentation layer shouldn’t be making decisions about the content. The presentation layer should be making decisions on how the content is presented. Doesn’t matter whether we’re talking about output to a web page, output to a file, or a report print out. Push that behavior out of there and put it in a model object where it belongs. This has the additional benefit that you can create unit tests to check the content before it gets to the presentation layer. I’ve found that after I extract this behavior and put it in the model where it belongs, an enhanced unit test is needed. Often that new unit test will also show there were bugs in the original implementation.

5. I’d like to make a comment about performance related code changes. In some cases you’re working on a fix that just requires the system to operate more quickly. Classic techniques include caching values, optimizing loops and removing unneeded code. The trick about performance improvement changes is that they almost always trade-off design elegance for performance. That’s okay, but remember that it can also make the code more brittle and easy to break in the future. Before you embark on performance improvements in code, ensure that you have sufficient unit test cases to demonstrate that you haven’t changed the overall behavior. This can mean you have to make some unit tests much richer and add checks for a lot of “fringe” model conditions. And like I used to say when I conducted performance tuning workshops years ago, know when to stop, and measure what’s really happening. Don’t optimize code that isn’t slow.

That’s it. These are lessons I’ve learned from mentors I’ve had the privilege of working with as well as lessons learned from doing things the wrong way myself. These lessons were also learned by seeing other developers get into a mess because these ideas were not considered.


Using Squeak to Create Desktop Wallpaper

Posted by steve | Smalltalk | Tuesday 20 January 2009 9:27 pm

I wrote a simple step-by-step example of how to use Squeak to create a colorful radial gradient desktop wallpaper.  It’s not difficult to follow along if you have some basic Squeak skills.

The tutorial is here: Wallpapers tutorial.


Progress on the 2008 Squeak Tutorial

Posted by steve | Smalltalk | Thursday 13 November 2008 4:32 pm

In the Summer of 2007 I wrote an extensive Squeak tutorial and posted it as a web site. It’s been well received. I still get weekly e-mail messages from students learning how to program in Squeak using the tutorial.

This year I began a rewrite of the tutorial. This time it will be available in book form. I’m also changing a lot of the content to reflect two significant user groups.

I’ve gotten letters from students who had no previous experience programming in Squeak. And they sometimes made the simplest of mistakes. When the tutorial was written this was not my intended audience.  I was shooting for an audience that already had experience programming in Squeak but wanted a deeper and more complete example to follow.  I wasn’t anticipating the tutorial being used by students new to coding in Squeak.

The second fundamental change has to do with a better marketing message about Squeak.  I wrote the tutorial using the base Squeak image as available from This approach was, I felt, the most reliable since it would always be available from the main Squeak web site. I knew that beginning with the base Squeak would not be the environment used by the more experienced Squeak developer. You can see the built-in conflict here. It’s also true that the base Squeak image doesn’t look as appealing to developers coming from other development environments. So with this rewrite I begin the tutorial using the DevImage instead. That image has many useful tools and features built-in and is highly regarded by the Squeak community.

I began the rewrite early into this year but there have been numerous setbacks, including serious health problems and a lot of “distractions” both good and bad at work. I have finally begun again to write the book.  And I’m making progress.  I wanted to take a moment here and share a little bit about the tools I’m using to do this.  The goal is to create a great PDF file which can then be used for self-publishing at places like LuLu.

Here’s the primary writing tool I am using. It’s called Scrivener and can be found at Literature and Latte. Here’s a screenshot of my work in progress.

The cool thing about Scrivener is it’s so easy to organize my ideas.  It also has the ability to export directly to LaTex format.  That’s awesome.  Once I create the LaTex output file I process it with TeXShop. Here’s a screenshot of that tool being used.

All of this creates a standard PDF file.  Here’s an excerpt from the beginning of one of the chapters.

So I’m having fun working on my tutorial again.  Finding time to do this is often difficult, but I’m making progress.


Repeat Post: Smalltalk Jobs

Posted by steve | Smalltalk | Wednesday 29 October 2008 2:41 am

There are choices when it comes to finding Smalltalk development work in today’s world.  What is an appropriate choice for a grey-bearded seasoned Smalltalk professional?

I was thinking about the Smalltalk jobs market again recently.  And it occurred to me that I may have the wrong perspective.  Consider that there are only a few real options.

The first option that comes to mind is to find a team that is already developing or has developed a Smalltalk application.  Another option is to join a development team at one of the Smalltalk vendors — improving the product for everyone else to use.  You could also do this by contributing to open source efforts such as Squeak, but I did say this was about work that pays bills.

The trade offs are stark.  In many cases the existing Smalltalk teams are merely “treading water”.  They develop valuable software for their employers, but are often faced with the constant pressure to move to something “more modern”.  Remember when everyone was moving to Java?  Still goes on in some places. Maybe it’s now .Net and C#, or Ruby or something else that’s “this decade’s Hoola-Hoop.”  If you choose this path you have found useful work applying your skills.  But is it the best choice?

If you join one of the Smalltalk development teams, a rare opportunity when it happens, you rub shoulders with other accomplished Smalltalk leaders and make the products better for all of us.  However, they have their own unique pressures and conflicts.  And in a way, that’s reducing the number of Smalltalk developers out there in the real world.  Kind of the opposite of what a Smalltalk Evangelist should be doing.  (Although one of the best jobs I ever had was when I was developing Internet Banking Frameworks with Rebecca, Alan, Dilip and Chris at Digitalk).

But here’s the thing.  These options don’t grow the market.  If you’re a long time software evangelist seeking to increase the market visibility for Smalltalk everywhere, there’s another much more difficult option.  Create something new using Smalltalk, and do it where it’s never been done.

It’s a lot like “inventing the future”.

So I’ve been wondering how to accomplish this.  And the truth is I’ve done that before and it was remarkably successful.  Maybe a little revisit to how that happened will help chart out a path for an equally successful future.  I don’t have an answer other than to say out loud, “The right thing to do is create the jobs.”  At least right this moment.

I’ve been writing Smalltalk for 20 years now, in lots of interesting situations.  Here’s the story as best I remember it for one of those cases where Smalltalk was applied for the first time and led to a big success.  Forgive my little journey into the past here.  I’m hoping something comes out of writing this and sharing it.  Maybe something all of us can use.

It was in 1990.  At that time I was employed in the Engineering Department of a small manufacturing company in Ohio.  We were developing software for embedded process control systems.  It was all assembler and some PL/M stuff and a development product from DEC called MicroPower Pascal which could be ROM’d.  A since it was PROM-based, it wasn’t easy to change the software.  

I’d already been with the company 10 years and was writing software and managing a small team of 5 other developers.  In those days The Wall Street Journal was occasionally publishing articles about the next perceived wave of software development using Object Oriented Programming and something relatively new called C++.  The President of our company and my boss, the Vice President of Engineering, were reading these articles (and probably some others).  At that time we were all feeling the pain of high software maintenance costs and long development cycles, with the often missed project deadlines.  So I was asked to look into the new C++.

After playing around with it some and reading what other development teams had tried, I discovered that the biggest “trick” was to get the developers to “think” OO.  Not just use C++ to write C code.  This issue may sound familiar for companies that foolishly thought they could adopt Java and get OO development, since Java was a lot like C and easy to learn.  Little rant there.

I concluded that we should prototype our next product using Smalltalk.  We’d end up with better models and we could then rewrite in C++ when we needed the speed and professional quality that this “C-like” language was supposed to have.  And at that time I really believed that we would “port” to C++ when we needed the speed.  What made the choice of Smalltalk work was a number of factors.

First, we were already expected to be using some kind of OO tools.  And Smalltalk was at least heard of.  Second, I’d already been using Smalltalk/V Mac on my desktop computer at work for odds-n-end tasks and was quite familiar with how productive the environment was.  And third, the VP trusted me.  So we embarked on a project to create something totally new, in the process control industry too, using inexpensive 386 Intel machines running OS/2 and Smalltalk.  We had a mechanical engineering team work on enclosures to make this hardware feasible and my little software team embarked on a totally new idea.  To be fair about it, it helped that I already had Smalltalk exposure and I was able to develop some core frameworks the new application would be structured around, as well as the fundamental designs for user interface and communications.  So when the team got ramped up on Smalltalk, enough pieces were in place that made it easier for everyone to see where they could help.

The remarkable thing we did was develop a totally new product for the market in record time.  We went from concept to working demo, which was unveiled at a trade show, in 4 months.  We had software delivered and running on factory-floor systems 3 to 4 months later.  And the really awesome feat was that the development team started to roll out unheard of powerful new features for our product very quickly.  We took the market by surprise.  And the interesting thing was that we never had to “port” to C++.  Smalltalk was fast enough and very stable.  We did get one lucky break.  Intel had made the 486 processors available just a few months before we went to production and any lagging performance issues we were seeing were improved.  I remember the President coming to see me one afternoon to share how he could see everything had changed.  We used to take weeks to respond to problems, and he was amazed by how the folks on the assembly like were telling him how we made updates sometimes daily.

From a product success point-of-view, the previous product we had developed using Pascal and PROM based deployment, sold and shipped maybe 2 or 3 systems per month.  It was enough business for our small company.  The new product, with lower cost and real high-end displays and capability (all developed using Smalltalk) sold like crazy.  They started producing 2 or 3 systems per week.  When I left the company, a few years later, they were producing 2 or more systems per day and the product was the most successful in it’s market.

That’s the trick that needs repeating.  It needs to be done in several places.  And, as tough as this seems to do, I think the experienced Smalltalk developers out there need to promote and initiate this sort of activity whenever we can.  I’m not sure how to do that right now.  Truth is I’ve had my head down coding a lot of interesting projects for my existing employer, and so my tendency to see marketing is not what it used to be.

It’s just speculation.  But I still have a lot of optimism about ways we can leverage the excellent Smalltalk development world to make new and exciting products.  We can create Smalltalk jobs both for ourselves and others.  Maybe that’s our best purpose.

« Previous Page