Submitted by Dave Churchville on Tue, 2006-06-06 13:33.
Stop fixing that bug right now! You could be putting your project at risk without even knowing it.
When I first started developing software over 15 years ago, I thought that bugs were evil, and should never appear in any software. It was a matter of personal honor, integrity, and pride to eliminate any bugs.
Only one problem with that approach. There is an opportunity cost to every bug you fix. And there is a risk factor as well.
Submitted by Gavin Bowman on Mon, 2006-06-05 07:15.
The most common theme on Codesnipers lately has been information overload, which is just a small part of the wider topics of productivity and burnout. Bob’s been talking about the 80/20 principle in many different ways, but here he applied it to his RSS feeds list.
I’ve been trying something similar over the last couple of weeks, so I thought I’d share. At first it was difficult, because, believe it or not, I didn’t have a feeds list.
Submitted by Steve Moyer on Fri, 2006-06-02 13:02.
As any regular Dilbert reader will know, the dark side I refer to in the title of this post is "management". It's really easy for a good technical person to be promoted into management and, according to The Peter Principle, rise to their level of incompetence. My career (thus far) is a perfect example:
- Manager of technicians
- Engineering Manager
- Contract programmer
- Embedded Systems Engineerr
- Engineering Manager
- Director of Engineering
- Director of a Business unit
- Job(0) Current job
- Staff Engineer
- Manager of Systems Engineering
- Principle Architect
Notice anything different about my current job? (Bueller, Bueller, Bueller) It wasn't that I didn't like management (I knew that the first time I had more than 5 employees) ... it's that I figured out what to do about it!
Submitted by Bob Walsh on Thu, 2006-06-01 15:55.
"Have you been crammified by too much screensucking in your pilatorium lately? Are you frozoned and multifailing because your work environment’s gemmelsmerch is too high? Worry no more! Reverse that enjambleness, stop that whizilling! Acme Micro-ISV’s got the product for you!"
No, I’ve not lost my mind, nor am I channeling A Clockwork Orange, and no, this is not Word 12’s spelling checker running amok. The above is a host of new words recently minted by Dr. Edward Hallowell, a leading expert on Attention Deficit Disorder to describe the host of new information-related afflictions, maladies and crippling diseases starting to spread throughout the Information Society. Pay attention now – what you don’t know can hurt you.
Submitted by Peter Harkins on Wed, 2006-05-31 18:37.
Question: Isn't a domain-specific language just the same thing as a library? (Source: Pretty much everyone the first time they hear of DSLs.)
Answer: No, a DSL is much more than a library, and I have an example that won't make you say, "Well, sure, if you're doing something that esoteric..."
Submitted by Gavin Bowman on Wed, 2006-05-31 07:16.
On Monday, while US readers were observing Memorial Day, we had our own holiday here in the UK: the Spring Bank Holiday. Traditionally, it was for Whitsun, a moveable religious festival, but now it always falls on the last Monday in May.
I’ve been working to my own schedule for quite a few years now, so I only tend to remember our holidays if I try to book an appointment with someone. This time I said I’d call in and see a customer early this week, and they were kind enough to remind me not to come on Monday.
Submitted by Dave Churchville on Tue, 2006-05-30 14:48.
Before I start, let me just say that I've held positions as "Chief Architect" at a startup, as well as managed a group called "Systems Technology Architecture" at a large Fortune 500 company.
OK, now that we've got that out of the way, architecture is often the bane of successful software development. Focusing on creating the proper architecture for all systems can reduce the ability for a company to manuever quickly, and increase expenses to a level that only companies with huge IT budgets can afford.
Now, before the flame-throwers come out, let me explain.
Submitted by Steve Moyer on Tue, 2006-05-30 09:52.
As I mentioned in my first post, I recently spent 8 days without an Internet connection at home. Now I find that Bob Walsh has stolen a bit of my thunder with his last two posts ("80/20 Your information feeds" and "Signs of Plague"), but there's a broader implication to his last post; Where does all my time go? My week without Internet access, and the increased productivity on my mISV product forced me to, once again, revisit my old friend "the time study" (everybody groan here).
Everytime I mention this technique to people, they tell me "I don't have time to collect metrics on how I use my time". My contention is that you don't have time not to. If you spend an extra 15 minutes each day, it generally won't take long to realize an ROI (Return On Investment - Time is an asset just like money, only scarcer). If you're thinking about the full-blown type of time study pursued by large multinational corporations or the government (and those have their places as well), I'd have to agree. There are however, two methods that will serve the small organization or mISV well. The first is simply a mental exercise and the second is a quick-and-dirty paper study.
Submitted by Keith Casey on Sun, 2006-05-28 10:15.
If you were attempting to visit and read some of the articles last night (Saturday, 4-6pm EDT), you might have noticed some "new" stories appearing, disappearing, published, and a variety of other things. This was due to the testing of a new module that has been added to CodeSnipers to improve the content flow. No content was lost or changed anywhere in the system.
Submitted by Bob Walsh on Thu, 2006-05-25 13:00.
A few weeks ago I promised to start exploring here the 47 non-coding things you as a programmer have to do to build a successful micro-ISV. I will get to those, but before I do, we need to do some information feed swamp-draining.
Years (many) ago when I started programming, technical information came in the form of things called technical books. If you were lucky, one or maybe two of these items would be produced, published and make it to a bookshelf at Computer Literacy Bookstore in Silicon Valley about the programming language you worked with and flailed at day in and day out.
That was then, this is now.
Now, no matter how obscure the computational subject, API usage, OS bug there's a gazillion web sites, blogs, and especially RSS feeds pumping out info 24/7 on it. Like drinking from a fire hose? Nah. Try like being at the bottom of Niagara Falls, looking up.