Wednesday, December 06, 2006

Note to Self

I should probably also post about a bug's (or in Joel's terms "a case's") lifecycle, too. I sent out an email internally at work a while ago but I should probably follow up on that and post it for the intarweb to see, too.

I'll try to cover what fits my work environment and also what is generally true elsewhere.

I can find so many things to talk about to avoid trying to explain how the SRM works in Windows kernel-land, can't I? I've tried a couple of drafts, but it's not easy to just give the basic info instead of trying to explain the whole geeky picture. I obviously don't have the gift of technical writing. :-(

Bug vs Feature

I recently read this and was appalled. Why would any company intentionally seek out testers who enjoyed "a good debate about whether something is a 'feature' or a 'bug'"? (Neverminding that the OP's final quoted remark didn't actually ever have end quotes. And also never mind why I was looking at that - just keeping my options open, but I'm way too stubborn to quit my current job yet.) What a *total* waste of time. I'd rather have someone on my team whose hobby was counting ceiling tiles. At least that's meaninful. To someone. I would guess.

Much to my chagrin (or in the case of the link, Ohio's), I'm in that situation now, though. I sat in a meeting with person X who claimed that to his/her mind a "bug" is something that takes a little time to fix and a "feature request" is something that takes more time. I'm beginning to wonder where American (in this case) software engineers learn to speak English.

If you're playing along at home, please use your own Google-fu to verify these common definitions as they apply to software:

bug - a software defect

feature request - I'm gonna have to break this down a little. It's evidently not immediately obvious. A feature is a prominent aspect of something. Hmm. Not a very solid definition. Google-fo doesn't really get me much in the way of a meaty definition for "feature request" or "software feature". I guess I'll just try to make up a definition. Clearly a feature isn't a bug, right? So a feature request IMO is a request for a design change. Further, it must be not because of a defect in the software or the design. It's a request for extra originally unintended functionality. E.g. "Please make my blender also function as an AM/FM radio so that I can blend tasty smoothies while I listen to my favorite morning shock jocks."

I'm not even going to touch the "is it a bug or a feature" debate. The only important question there is "what's best for the customers?" and if there's enough data there should be no argument.

So I've put off my screed on (the next links mostly suck - don't bother) DACLs/SACLs/MACLs and also MIC (new in Vista, though the idea's been around for a while) until next time. Unless I get sidetracked again.

Actually, I might get sidetracked. I think I might need to explain threat modeling and even more so the terminology used ("threat", "DREAD rating", &c.). I keep running into "define that term" roadblocks at work. Rather than invest in dead trees, I think I might blog it.

Saturday, December 02, 2006

Strongly Considering Resigning . . . (and a bit of swearing)

(No linkies in this one. I'm too pissed off to bother. Next up (really) - a little more on the NT object manager and an intro to security descriptors/ACLs.)


After recent work experiences I'm very strongly considering resigning. (No - really. Very seriously. And wondering where I could go right now.) And wondering why I didn't apply for that Principal QA job at Symantec. Damn. That's right up my alley. And in the bay area no less. I'm such a sucker.

It doesn't seem to matter how many bugs I file. Nobody fixes them. (That's an exaggeration - out of the 100+ bugs open against our last release 2 or maybe 3 were fixed. The rest were punted to our new release. Forgive me please for exaggerating.) Even when I explain in *great* detail how to fix (step by step how to goddamned write the code) the bugs nobody bothers. Why do I do it? I really don't know any more.

It doesn't seem to matter when I find serious security holes in our product. I guess they'll be fixed in version 2.x . . . Maybe. If the customers are lucky. Or if that ever ships. I can only hope that customer X (that I don't think I can mention yet) *demands* a higher quality of crap than the current ESS anus spews. Maybe then quality will matter . . .

It also doesn't even seem to matter when I point out to our IT guy that one of our public-facing servers have *many* known vulnerabilities, at least one of which allows any unauthenticated attacker to shove arbitrary data onto the stack and overflow it. *grumble* That's almost surely exploitable and would give the attacker root on the box in our case. Worse yet, I hear that all of the accounts used to attach to those boxen use same/similar passwords. Our entire extranet is compromised. And maybe our intranet, too. Who's losing sleep over this? Maybe only I am. Goodbye, my sleep!

I'm this far from writing 'sploit code so that someone will listen to me: '-----'

I don't believe in ever writing 'sploit code. Ever. That's not only illegal (unless contractual and even then iffy) but immoral. But I'm at the point that I'm not sure how else anyone would ever listen to me when I say "this is a bug - please fix it ASAP".

Damn. Sometimes it sucks to be a (the only?) security geek at a "security" company. At an alleged "security" company, that is. Working on an alleged "security" product.


Shit! Part of me misses Microsoft . . .

(P.S. For anyone reading this internally at ESS, there are bugs filed. I can provide links if you can't find them.)

(P.P.S. Ray - about that alleged penetration tester who tried to attack us - EVERYONE who wants to take over a box knows about the app I used - it's been around forever. Please please please let me know what he tried. I think whatever it was it's severely lacking. I finally tried the most obvious test and found ways to break into all of out public-facing servers. This is *scary*.)

Thursday, November 30, 2006

File under: What WebSVN should have shipped with for Windows.

(Edit: adding links)

I recently deployed FogBugZ and got it integrated with my company's Subversion server. A piece of this was installing WebSVN so that the cool automagically-appearing links to sources and diffs would take users to useful web pages. I noticed the other day when I tried to diff versions of an RTF file that I got all kinds of formatting goo in my diff. That didn't make me happy. The solution was to set the svn:mime-type property on non-text files in our repository.

In the interests of community, I give you my batch file to automate those changes. It doesn't do the svn commit - you'll have to do that yourself or modify the batch file.

If anyone knows how to automatically have this happen on new files (autoprops is a per-client setting in the config file), please let me know.


@echo off
' This batch file adds svn:mime-type properties on non-text files.
' NB: The lines with file extension and mime types must start with two apostrophes
' and must have spaces between the apostrophe and the extension and between the extension
' and the mime type.
' Drew 11/30/06
'' 323 text/h323
'' acx application/internet-property-stream
'' ai application/postscript
'' aif audio/x-aiff
'' aifc audio/x-aiff
'' aiff audio/x-aiff
'' asf video/x-ms-asf
'' asr video/x-ms-asf
'' asx video/x-ms-asf
'' au audio/basic
'' avi video/x-msvideo
'' axs application/olescript
'' bcpio application/x-bcpio
'' bin application/octet-stream
'' bmp image/bmp
'' cat application/
'' cdf application/x-cdf
'' cer application/x-x509-ca-cert
'' class application/octet-stream
'' clp application/x-msclip
'' cmx image/x-cmx
'' cod image/cis-cod
'' cpio application/x-cpio
'' crd application/x-mscardfile
'' crl application/pkix-crl
'' crt application/x-x509-ca-cert
'' csh application/x-csh
'' css text/css
'' dcr application/x-director
'' der application/x-x509-ca-cert
'' dir application/x-director
'' dll application/x-msdownload
'' dms application/octet-stream
'' doc application/msword
'' dot application/msword
'' dvi application/x-dvi
'' dxr application/x-director
'' eps application/postscript
'' etx text/x-setext
'' evy application/envoy
'' exe application/octet-stream
'' fif application/fractals
'' flr x-world/x-vrml
'' gif image/gif
'' gtar application/x-gtar
'' gz application/x-gzip
'' hdf application/x-hdf
'' hlp application/winhlp
'' hqx application/mac-binhex40
'' hta application/hta
'' htc text/x-component
'' htm text/html
'' html text/html
'' htt text/webviewhtml
'' ico image/x-icon
'' ief image/ief
'' iii application/x-iphone
'' ins application/x-internet-signup
'' isp application/x-internet-signup
'' jfif image/pipeg
'' jpe image/jpeg
'' jpeg image/jpeg
'' jpg image/jpeg
'' js application/x-javascript
'' latex application/x-latex
'' lha application/octet-stream
'' lsf video/x-la-asf
'' lsx video/x-la-asf
'' lzh application/octet-stream
'' m13 application/x-msmediaview
'' m14 application/x-msmediaview
'' m3u audio/x-mpegurl
'' man application/x-troff-man
'' mdb application/x-msaccess
'' me application/x-troff-me
'' mht message/rfc822
'' mhtml message/rfc822
'' mid audio/mid
'' mny application/x-msmoney
'' mov video/quicktime
'' movie video/x-sgi-movie
'' mp2 video/mpeg
'' mp3 audio/mpeg
'' mpa video/mpeg
'' mpe video/mpeg
'' mpeg video/mpeg
'' mpg video/mpeg
'' mpp application/
'' mpv2 video/mpeg
'' ms application/x-troff-ms
'' mvb application/x-msmediaview
'' nws message/rfc822
'' oda application/oda
'' p10 application/pkcs10
'' p12 application/x-pkcs12
'' p7b application/x-pkcs7-certificates
'' p7c application/x-pkcs7-mime
'' p7m application/x-pkcs7-mime
'' p7r application/x-pkcs7-certreqresp
'' p7s application/x-pkcs7-signature
'' pbm image/x-portable-bitmap
'' pdf application/pdf
'' pfx application/x-pkcs12
'' pgm image/x-portable-graymap
'' pko application/
'' pma application/x-perfmon
'' pmc application/x-perfmon
'' pml application/x-perfmon
'' pmr application/x-perfmon
'' pmw application/x-perfmon
'' pnm image/x-portable-anymap
'' pot, application/
'' ppm image/x-portable-pixmap
'' pps application/
'' ppt application/
'' prf application/pics-rules
'' ps application/postscript
'' pub application/x-mspublisher
'' qt video/quicktime
'' ra audio/x-pn-realaudio
'' ram audio/x-pn-realaudio
'' ras image/x-cmu-raster
'' rgb image/x-rgb
'' rmi audio/mid
'' roff application/x-troff
'' rtf application/rtf
'' rtx text/richtext
'' scd application/x-msschedule
'' sct text/scriptlet
'' setpay application/set-payment-initiation
'' setreg application/set-registration-initiation
'' sh application/x-sh
'' shar application/x-shar
'' sit application/x-stuffit
'' snd audio/basic
'' spc application/x-pkcs7-certificates
'' spl application/futuresplash
'' src application/x-wais-source
'' sst application/
'' stl application/
'' stm text/html
'' svg image/svg+xml
'' sv4cpio application/x-sv4cpio
'' sv4crc application/x-sv4crc
'' t application/x-troff
'' tar application/x-tar
'' tcl application/x-tcl
'' tex application/x-tex
'' texi application/x-texinfo
'' texinfo application/x-texinfo
'' tgz application/x-compressed
'' tif image/tiff
'' tiff image/tiff
'' tr application/x-troff
'' trm application/x-msterminal
'' tsv text/tab-separated-values
'' uls text/iuls
'' ustar application/x-ustar
'' vcf text/x-vcard
'' vrml x-world/x-vrml
'' wav audio/x-wav
'' wcm application/
'' wdb application/
'' wks application/
'' wmf application/x-msmetafile
'' wps application/
'' wri application/x-mswrite
'' wrl x-world/x-vrml
'' wrz x-world/x-vrml
'' xaf x-world/x-vrml
'' xbm image/x-xbitmap
'' xla application/
'' xlc application/
'' xlm application/
'' xls application/
'' xlt application/
'' xlw application/
'' xof x-world/x-vrml
'' xpm image/x-xpixmap
'' xwd image/x-xwindowdump
'' z application/x-compress
'' zip application/zip

' If svn.exe isn't in the %path%, bail out.
svn.exe help >nul
if 0 neq %errorlevel% (
echo You must have svn.exe in your path to use this batch file.
goto EOF

' The evil for loops that do all the work (including parsing this batch file).
for /f "usebackq tokens=1,2,3" %%i in (`type %0`) do (
if "''"=="%%i" (
for /f "usebackq tokens=*" %%l in (`dir /s /b *.%%j`) do svn ps svn:mime-type %%k "%%l"

A Post Without Substance

I keep either forgetting to write something here or I'm too busy/distracted/in need of non-computer-related activity that I've been ignoring my blog. :-(

So even though I don't have anything of substance to post right now, I thought I'd put this up. It's my latest get rich quick scheme. I was reading Joel's blog and I found inspiration. Pretend I'm E. F. Hutton. Here we go . . .


I can get rich by shorting spam stock. Not only is it a foolproof investment, but I'll actually have a way to make money *from* annoying spammers! Sweet, eh?

Am I brilliant or what?

Yeah. I know: what.

Tuesday, November 07, 2006

So Finally Something About Security? The NT Object Model.

I keep meaning to start a series abut security. At least on Windows (NT family).

First, I should start by explaining the object manager. Then again, let's let someone else do it. Adrian groks this stuff. Check it out:

(off topic) If you enjoy that you may enjoy Adrian's explanation of the NT heap manager:

And if you want to kill some trees, I strongly recommend this for anyone into how Windows does its thing:;show_locs=no

Tomorrow: a recap of what to know about the object manager as far as security goes, then an intro to access control lists (ACLs).
Day after tomorrow: I'm planning a dive deeper into ACLs - ACEs.

Please, someone, give me some feedback if you want to see how this relates to Unix, Unix-based systems (Linux, OSX, etc.) or to the NT predecessor (VMS (link is to Open VMS)).

Wednesday, October 25, 2006

Put Away the Crayons

After that initial blue sky period which I prefer to think of as "huffing ether", we start to get down to the nity gritty. PMs drive writing functional specs. They *must* have buy in from dev and test, of course - t's that three legged stool thing). At that point, devs can ground the pm wish lists in reality and testers can try to find spec bugs before any code is ever written. Then simultaneously (ideally) dev writes up a more technical spec and test writes a test plan.

This is subject to a great deal of debate right now. There are many people calling for "agile development methods". Frankly, everyone I've ever known has used some of those agile methodologies whether they called them that or not. As someone focused on quality, I see the advantage in test driven development. And I've certainly led scrums in the past, though we didn't call them that. Whatever it takes to get a cohesive team building kick-ass software (just kidding with that last link). I'm not going to argue or belabor the point any longer. These things are as trendy in software as cargo cult efficiency methodologies are in *real* engineering.

While the devs and testers are busy trying to find ways to implement the master spec in their own realms, the pms try to guide them and start to push for schedule SWAGs (not those SWAGs, but these). Oh - and don't forget prioritization. Somewhere in this mess of people scurrying about, the pms drive prioritizing the work that will need to be done both in terms of the features set forth in the pm's (pms'?) spec and in terms of the actual work items for everyone involved (called out by dev and test in their docs).

Sometime soon after this, the devs and testers start coding. I'm not sure what the pms do at that point except keep asking more questions about schedule and priority. Oh - actually I *do* know. The pms do what they're infamous for - they try to push new features into the product. This is a continual process for them. It's why they're paid. Or why they seem to think they are. Frankly, feature creep seems like a sign of too many pms late in the cycle or too little pm thought early in the cycle to me. The venerable Brian Valentine is known within Microsoft's Windows division for the times during the product cycle when he declared that (my paraphrasing) "developers should fix bugs, testers should verify fixes and continue to find new bugs, and pms should get the hell out of the way". (Yes, any other fans of Patton out there might recognize this as being similar to "lead me, follow me, or get the hell out of the way". I leave it as an exercise for the reader to determine how close or distant BrianV was to/from Patton.)

Additionally, pms will drive cross-team initiatives. This is generally good news because it means that they're trying to make work for other teams and not yours. And if it's a pm from another team it's pretty easy to duck the work. Win-win for the people actually producing the software. If you're lucky your pm will prove to be a wonderful asset during this make-work phase because (s)he can be the bulldog that fights off other pms who try to take your time away from the job at hand: making all those new features work in less time than it is probably humanly possible. In a shop as small as mine is, that's not as likely, of course. But I'm writing mostly about economies of scale.

I should probably call out an assumption at this point: testers contribute to the bottom line. In many places testing is an afterthought. Preferably (IMO) not an after-market thought. In others, testers are integral to producing a product. In some (and I've seen/heard about them - they exist) testers are little more than a drain on everyone else's resources.

When things are balanced, I see it this way:

PMs - Gather requirements and drive prioritization and scheduling. They're the connection to marketing and customers when people wish for new features. They are primarily motivated by making "cool things" (which may or may not even be technically possible) happen.

Devs - Write the code. They are concerned with maintainability of their code base and understanding the deeper knowledge of what all their code does. They are primarily motivated by making "cool code" (which may or may not correspond to what customers need or want) happen.

Testers - Test the code. They are concerned with the stability/quality of the product and how it interacts with anything else out there. They are primarily motivated by not letting customers ever see any bugs (which is both impossible and tends to be contrary to adding the changes that devs and pms want).

Why do I start out with more silly links than I have toward the end? I think I usually begin in a whimsical mood and end on a much less whimsical one. I should think about this a little more and maybe change up my style . . .

Stupid sbemail link.

Sunday, October 22, 2006

Crayons on the Tablecloth

After a hiatus (much needed both because of worky work stress and my first cold of the season), I'm back. On the topic of worky work, we shipped Taceo 1.7. It sucks a lot less now. It's still kind of nasty but so much better that I'm not so embarrassed if you try it. I should blog a little about what we actually sell and why consumers might want it, but I'll leave that until later. Maybe when I need a break from working on my Halloween costume.

I decided that before defining each job function more clearly I'd walk through a typical development cycle and try to point out everyone's roles. This installment is about that initial pre-pre-pre-design phase. Or maybe it's still design. Either way, it's the thing that comes before people even start to write specs or plans or schedules. Consider writing a rougher than rough outline of an idea on a tablecloth. In crayon. It's like that.

Yes, usually the concept is supposed to happen from napkins but I want to emphasize something beyond that. It's BIGGER than a napkin. It's more substantial. Ok, so who am I kidding? This is all about designs on a napkin. (Why is it that GOOG can't find any of the Picasso napkin sketches I wanted to use as links here? *grrr*)

Typically a PM has some idea of the product, the market, and how to help the product suit the market better. To the PM this is the goal. Fairly close, but there can be a lot of impossible demands from the blue sky PM.

Typically (after v. 1, at least) a dev has some idea of how to beautify and/or extend his/her code. And to the dev this is the goal. This is technologically possible but often totally disregards the customers.

These are two goals.

Two entirely different goals.

. . .


If you work where I work, this may seem all too familiar. It's not exactly desirable. But it's a common pattern. I know I saw it when I was borg, too.

Typically, test comes in after this point. I don't think it should but it does. I won't press this point but suffice it to say that there's something wrong with the pattern.

During the blue sky phase of a project lots of ideas are bandied about. Pm typically has a wishlist from particular customers and/or marketing. Most of which aren't feasible as written. Dev typically has some desire to refactor the code they've been saddled with supporting during the last release (because refactoring *always* makes everything better to the devs). Most of those cosmetic changes will take a very long time and add little value to the product. And test is usually left out. Mostly because it's still busy finding the bugs that the devs left in the last version of the product.


So that's how it usually goes. But how *should* it go?

It should be a partnership from the start. And PM/dev/test should approach a new problem with open eyes but with full knowledge of the limitations of whatever existing system. PMs specialize in being a cross-group/customer/marketing bridge. They do personal politics that are tempered with a fairly solid understanding, technically, of the product/component they own. Devs approach things from a more pragmatic code-focused point of view. They want to make the best software that they can to meet customer needs while requiring as little of their time later in the cycle to support it. Cleverness up-front will be rewarded by less scutwork later. Testers start to test every assumption made about customer demands or the market or some dev's idea of time-saving or even what group X *really* wanted. This saves them (and the rest of the team) time and money later. Together, all three flesh out what the spec should look like before the spec is ever written.

But, obviously, this doesn't always happen.

(P.S. Sorry if I'm a bit test-centric. That's my world at the moment. I've worn different hats in the past and I'm sure I will in the future, but at this time I'm a little too focused on being a tester at my startup.)

Saturday, October 07, 2006

The Three Legged Stool of Software Development

I gave up on "trinity" as the analogy pretty early on. "Tricorn hat" also didn't work. Nor did "three bowling ball holes" of software development. "Threepenny Opera" also didn't cut it. "3 Inches of Blood", while it had a certain appeal, also didn't quite work. So I finally settled upon the "three legged stool", so this blogpost is now hereby about the three legged stool of software development.

Why a three legged stool? There are three disciplines typically involved in the process: development, program/project management, and testing. Each of those disciplines has a role and each of those roles need to 1) exist and 2) be balanced with the others. Imagine a two-legged stool. For whatever reason, Google Images has failed me, so you'll have to imagine it instead of looking at a pretty picture. Without the third leg (you wouldn't believe the GOOG hits for "third leg" - unpublishable!), that stool is either going to fall over or have some outside force to keep it upright. Now imagine a three legged stool with legs of unequal size. All legs touch the ground, but the seat of the stool just isn't level (forgive me for the cheesy link, but I love that about SF!). In software development that just can't be right. So we try to have a stool with equal legs of dev, pm, and test holding up the seat of the software, of the customer. Keeping things on the level.

Synopses (I'll probably post more detail about these later):
Developers - write the code, fix the bugs.
PMs - drive cross-team collaboration, drive the design and the schedule.
Testers - test the code, file bugs, confirm fixes.

Those synopses leave out a lot of details. Everyone has equal input at all stages of the product cycle, for example (thank me later for no prescriptive/proscriptive PLC links so far). I should probably explain the product cycle and the duties within it before I go on too far. I really need to get into granularity of duties among leads, senior staff, and junior staff, too.

I'll just leave you with one of my favorite Patton quotes for now:
Lead me, follow me, or get out of my way.

Next up: Either a better definition on disciple duties, an overview of the product cycle, or my thoughts on leading vs being an individual contributor.

Sorry to anyone expecting more security geekery so far. If you want that, look only here and here. :-) My head has been too wrapped up in procedural junk at work to be worried much about security lately. Eventually I really will get around to the NT security model and how it compares to others in the industry or even to ideals.

This page is powered by Blogger. Isn't yours?