Ask Zompist: Cloud computing

Since ideas like cloud computing are taking center stage, are arguments against open source losing ground?

Also is the current move toward the cloud a good thing for software or not?

—Joe Baker

My last job was in a SaaS company, so I’m familiar with some of the advantages.  It’s great for the seller— you get ongoing revenue instead of single sales; you can easily update all your customers— and it has advantages for enterprise customers: easily deployable, centrally manageable, presumably more reliable.

I think it makes the most sense for side apps— things like source control or survey software that you want to be widely available, but aren’t where most people spend most of their working hours.  For main apps, local teams, not the head office, should be able to choose the best tools.  If I’m spending most of my day using a tool, my team will make a better choice than some clueless IT autocrat.

I’m dubious about cloud computing in general, because there’s all this power in the desktop computer— why avoid it?  It mostly seems like an end run around Microsoft.  But if it works, it won’t produce the Open Source Utopia; it’ll produce a software world dominated by Google rather than Microsoft.

Also see Joel Spolsky’s delicious takedown of the architecture astronauts, particularly Microsoft’s version of cloud computing.

You mentioned Steam, which is an interesting model… it has cloud computing elements, in that your game permissions are stored externally (which makes it easy to change computers— a great boon as I’ve done it twice in the last year), yet the apps it manages are local desktop apps (which makes a lot more sense for games).  That’s a good balance, taking the advantages of cloud computing but not forcing it to do what it’s not good at.

 

The design department

I thought I’d write about the design process at SPSS, since it seems to be somewhat unusual in software shops.

Generally, as Alan Cooper has lamented, programmers design the products.  At SPSS there was a separate department responsible for design.  “Design” here means functionality plus UI.  They would write design documents specifying every screen and dialog, every error message, every command and what they did, every statistical procedure and how it worked.  (As preparation for this, they would decide on the functionality required, talk to users, and check out the competition.)

These would be reviewed in meetings, normally attended by all the stakeholders: sales, marketing, development, statistics, QA, documentation, tech support.  The designer led the meeting, and the best ones were good at keeping the meeting on track.  Meetings lasted no more than two hours (after that, people get bliffy); it it took longer another one was scheduled.

Anyone could criticize the design, and did.  However, there was a rule that the meeting shouldn’t fix designs, the designers should.  After an issue was raised the designers would go back and rework that part of the design.  Trying to design a feature in a meeting produces endless discussion and wastes most attendees’ time.

Most of the designers were smart and of course were experts in the product line, and the process normally worked well.  The weak spot was if anyone wasn’t really paying attention– people who hadn’t read the document ahead of time, or had little to say, or for whatever reason hadn’t bought into the product.  On the other hand, they didn’t have much of a leg to stand on if they didn’t like the product once it came out.

The designer continued to work closely with the development team, keeping the design up to date, helping to solve problems as they came up, doing usability tests, and participating in bug triage sessions.

Why would you do this?  Well, there are several advantages.

• It’s a huge benefit to QA and doc writers, who know what the product is supposed to do long before they get any releases.
• Designers can make sure different products are consistent, and as specialists they can produce better, easier UIs than programmers (who like arcane incantations). 
• It formalizes the functionality– which helps keep your manager or the CEO from rushing in a month before ship and trying to slip in a new feature.
• A good design document won’t just say what the program does, but why.   This helps avoid mistakes later, and educates everyone about what the product means to the end user. 

Does it add time to the development process?  It does take time, though the bulk of the work can be done while the dev team is finishing the last release, and designless products (as Frederick Brooks explained decades ago) end up late anyway.

For a tiny software shop, it may seem like a luxury– though I worked on a product at SPSS for years that had 4 to 6 programmers, and there was enough design work to have a full time designer. 

A much larger firm may have a much more elaborate design process; an advantage of the SPSS system is that it’s really not that complex.  The essential deliverable was a single design document; sometime there’d be a functional spec first.  When we had time, the developers would produce a internal design doc as well.  No one was drowning in paper.

 

Microsoft modulo 2

Microsoft has a very strange pattern of alternately creating great and horrible things for programmers.  The Windows SDK was difficult; MFC was great; COM was a nightmare; C# is a dream; LINQ has gone back to the Dark Side.

Here’s my first working code, which took forever and probably could be done much better… with two books plus the web as reference, it was hard to do even this much.

SqlConnection conn = new SqlConnection(
   @"Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\TestDb.mdf;Integrated Security=True;User Instance=True");
SqlCommand comm = new SqlCommand("SELECT * FROM People", conn);
SqlDataAdapter adapter = new SqlDataAdapter(comm);
DataSet ds = new DataSet();
adapter.Fill(ds);

var results = from t in ds.Tables[0].AsEnumerable()
                          where !t.IsNull("Level")
                                && t.Field("Level") > 6
                          select t;
foreach (DataRow row in results) {
     this.ResultsLabel.Text +=
                    string.Format("{0}: {1}\n",
                    row["PersonID"], row["Name"]);
}

Ugh.  I appreciate the idea of adding SQL support directly to the language, but this really doesn’t seem easier than, say, using SQL, something we’ve been able to do for years.  Compare the equivalent SQL query, in fact:

SELECT PersonID, Name FROM People
WHERE Level IS NOT NULL AND Level > 6

Microsoft has gone to a whole lot of work to make something that kind of looks like SQL but isn’t. The compiler is much smarter in some ways (e.g. it will figure out many data types from context) but not enough– it seems entirely arbitrary what objects can be used in a LINQ query and which can’t. It’s particularly annoying since Visual Studio is smart enough to make it easy to create a database for you, and it will create some accessor objects for you… and then I have to mess around with connection strings and string column names in the code.  (Come to think of it, I’m making an actual SQL query in order to make a fake SQL query.  Why is this a good thing?)

I’ll get better at this soon; I’m just picking it up, so I’m in the ranting stage. But I wish the Light Side had been allowed to work on this. So far it looks like what Joel calls “Fire and motion“: Microsoft messing with things in hopes that they can move forward while everyone else is forced to catch up. If they’d made database queries easier, that would be cool, but so far I’d rather write the SQL.

 

Why Johnny Can’t Document

I had some plans for a massive web page on software and software management, but it occurred to me that it’d be better to blog about it instead, in dribs and drabs. So here we go.  (I should mention that though I’ve worked in the industry for 25 years, it’s all been in software shops.  I recently interviewed with a huge megacorporation that can afford to have 150 people paid to do nothing but write architecture documents; that’s another world and I can’t help you there.)

Today’s question is, why can’t programmers write documentation?  Are they just lazy, or what? 

The brief answer is, it doesn’t match how they think.  Programmers are good at dividing a huge problem into little pieces, chunklets simple enough to be understood by a pedantic idiot, that is, a computer.  It already takes a special mind to be able to think in terms of the little pieces and to master the petty, arcane way the idiot insists on being addressed in.  It’s rare that the developer can talk to human beings as well.

If you corral the programmers into a room and force them to address the lack of internal documentation– something they’ll readily admit is a Bad Thing– then they’ll come up with a way to make documentation look like code, or come out of code.  They’ll look at something like this method signature

public void Deposit(decimal amount) 

and produce something like this:

Method name: Deposit
Return value: void
Description: Make a deposit
Argument list:
     amount    decimal    (input)    amount to deposit

In other words, their idea of documentation is to list out what’s obvious to any programmer reading the method signature.  This does nothing except create something else to maintain or more likely to get out of sync with the code, but to the programmer it has the advantage that he can write a program to generate the “documentation” automatically. 

In a small software shop this sort of thing will be done for one or two code files and then quietly forgotten.

What do you do instead? 

If you really want internal design documents– and they are nice for training other programmers, for debugging, for sharing techniques– then you have to make time for them.  Developers don’t include design or documentation in the estimates they give, and since their estimates are low anyway, they’re usually skipped.  So include the documents as deliverables and make time for them in the project plan.  (Often there’s downtime at the beginning of the project anyway while the honchos are arguing over what to do, so that’s a good time for this.  This is also when the code is freshest in people’s minds.)

At my last job we had a wiki for design, ideas, documentation, whatever.  That works– at least, it works better than paper.  In this area the perfect is the enemy of the good: creating good paper documentation is difficult and time-consuming and people tend not to do it.  Slapping the best bits from an e-mail chain into the wiki, by contrast, takes only a few minutes.

The best place for documentation, though, is in the code.  Good programmers should explain what the major methods do, what the class is for, and any tricky procedures or formats, right in the code.  The code is where programmers look anyway, and since the comments are right there, they’re more likely to be maintained.  And it’s in the source control system and requires no extra tools.

(How do you get even that?  The surest way is to do code reviews, which I’ll talk about another time…)

 

Joel made easier

Joel Spolsky has redesigned his site, highlighting his best articles, divided by job title (developer, manager, UI designer, CEO, etc.).  It’s a good excuse to go read or re-read them.

http://www.joelonsoftware.com/index.html

Joel is very smart, though he hides this with an easy, humorous style, and his advice is always sensible– generally tossing cold water on panaceas and rigid systems.  I think he’s particularly good on management of software projects, but the site is like candy– you can just keep reading good, thought-provoking articles all day.