Jott user story

What a great, simple example of a user story for how the speech-to-text service Jott can take your voice message and post it to your Blogger blog.

They same mechanics can be done in plain text, but how much more entertaining is it to read in comic book / retro clip art style?

SW Methodology Choices

This presentation, Selecting a Development Process: Choosing Among the leading alternatives ,
serves a good intro.

I hadn't heard much about OpenUP, but it sounds like what RUP should be.

Amatuers talk tactics; professionals talk logistics.

While cleaning out my car I saw a random receipt with this unattributed quote, unsafely scrawled down while driving, which I heard from some military officer talking on NPR.

It instantly rang true to me with respect to writing software; it rang so true that I risked life and car to transcribe it rather than lose it along with all the other jokes and truisms I hear and promptly forget.

The quote gets at why I'm studying Software Engineering:
Logistics in the world of software is Software Engineering .

Any clever person with a reasonable grasp of boolean logic can code; that is tactics. To build a software system that does what users really need, that will last for years, and works for more than 100 users, then do it again on the next project, and again- this takes logistics.

security lifecycle

Security isn't something I like to think about, but for applications that have a large number of users it's a real consideration.

This artical talks about not just about the act of 'securing code', but about integrating it into your development process.


How Do They Do It? A Look Inside the Security Development Lifecycle at Microsoft -- MSDN Magazine, November 2005

good links:
application verifier
PreFast
SAL

Dependable Embedded Systems

This is a serious course in dependable embedded systems at CMU's main campus.



18-849 Dependable Embedded Systems

Project Portfolio artical

This artical claims that businesses are only getting 60% of the value from their work due to poor decisions in portfolio management.

If anything, the whole Part I section is a great read for the most common kinds of decision makeing biases.

Expert Project Management - Choosing the Wrong Portfolio of Projects: Part 1

Code inspection would have been faster!

So, I've read the white papers, I've done a 7 week intensive PSP training course, I believe what the experts say about code reviews being faster to find bugs than conventional debugging.

But this morning I spent 3 hours chasing a bug that would likely have been caught in code inspection: I was using the wrong loop index name. dang.

It would have been caught as a compiler error if I were in C++ (do to delcaring the loop index in the for loop) but I'm doing C on a little 8051 with 16kB of code space and 1280 bytes of RAM (yes, bytes).

Another excuse (but an excuse nonetheless): I was having debugger problems, to the tune of semi random crashes of the IDE, necessitating hard power cycle of board and debugger, with a little vitamin reboot on the PC thrown in for good measure. Since the tools have been rock solid up till now, and they're relatively new to me I didn't want to wallpaper over problems, so I ruled out bad hardware, bad USB cables, out of date IDE/debugger software and firmware. Maybe because I was using 1154 of my 1280 RAM bytes? Commenting large blocks of code helped in a similar way that I feel like my car runs better after an oil change.

In the end printf debugging made me actually look at what the hell the code was doing. Why didn't I dash off a hard copy of the code and read it in the first place?

Code as Design: Three Essays by Jack W. Reeves

Discussion provoking essays on a topic near and dear to me: What exactly is software design?

Contrary to some people's take on the artical, he's not saying that the source code is the design. He is arguing that the code is an element in the design.(after looking for a link to some loud mouth declaiming "The source code is the design", if found a great wiki page that reiterated my premise above)

Building a piece of software is like building anything else: the number of people that interact with the product, the strength of those interactions, and the expected lifespan of the product determine the necessary rigor of its design process.

developer.* - Code as Design: Three Essays by Jack W. Reeves