Skip to main content

Posts

Showing posts from 2014

Fwd: Great Article on Code Review

http://blog.salsitasoft.com/practical-lessons-in-peer-code-review/ Consequences of bad reviews Not having time to deal with your review backlog. Delaying a release because your reviews aren't done yet. Posting reviews that are no longer relevant since the code has changed so much in the meantime. Doing poor reviews since you have to rush through them at the last minute. Ideas >>  something around 25% of the original development time should be spent on code reviews .  >> understand how the code fits into the larger context of the application, component or library it is part of. If you don't grasp all the implications of every line of code, then your reviews are not going to be very valuable. >>    empty their review backlog every day.   Fix One Area At A Time >>   If my colleague spends a week adding code willy-nilly across a large project then the patch they post is going to be really hard to review.   >>   creating reviewable code is to  annotat

AppleSoft

I'm not TRYING to be "fanboy-flame bait" but what I saw yesterday was a typical "Do it this way, now do it this way and then we'll go back to this way" all over again.... a move similar to what Microsoft does to developers on an ongoing basis. Remember the first iPhone? Smooth and curved, at least as far as it could be back then. I still pull out my 3G and can see the curves on it. Then the 4 came out and "boxy" was all the rage. Everything should be "tight with corners" Now iPhone 6.... smooth and curvy is back. Granted I don't have the actual device yet, but that's the message. Guess that means the iPhone 8 will be back to boxy. And honestly, Apple Watch is not worth " one more thing " --- especially when everyone knows it's going to be shown. "One more thing" would be something no one saw coming.  The device itself ? Very interesting and yes, definitely lots of potential but "one more thin

WPF - Setting Up Themes

Forcing WPF to use a specific Windows theme | I Got Rhythm At a client recently, we developed our WPF application under Windows 7, tested it under Windows XP and everything looked great.  Then it was deployed. As it turns out, one of the deployments was over a Citrix server that forced applications to run under Classic mode.  Those of you who have worked with various operating systems over the years will know what I'm talking about. Classic mode isn't quite classic, unless you are one of the few who think playing bar pong on an 84" TV is superior to playing one of the more dimensional games. Or maybe one of the few who like to get up and change the TV channel rather than finding the remote. Or one of the .... (you get the idea) While most things converted well, Tabs do not. In WPF, we have these beautiful tabs that look fresh but over in Classic mode, they have the look and feel of, well, Classic Windows 95 and VB 6 applications. The application was demo'd to the clien

New FoxShow Episode featuring Southwest Fox 2014 Organizers

The latest version of the FoxShow ( FoxShow #79 - Southwest Fox and Southwest xBase++ 2014 ) features an interview with Rick Schummer, Doug Hennig and Tamar Granor about what they have planned for this year's Southwest Fox conference, fast approaching in October. If you haven't registered yet, be sure to listen for a special offer from Rick in the show. Hope to see you there! FoxPro VFP

Timetracking and Cool Tool Alert: SonicAgile Project Management

    Sometimes a blog post talks about a tool and it sounds like an ad. Othertimes, it provides good information and then it mentions a tool. Such was the case when I read this post from Stephen Walther. The explanation of time-tracking (second paragraph) really hits home when trying to promote why it should be used. I've been working with Microsoft's TFS for the past few years and one of the challenges has always been getting people to track time. If they don't see a real benefit to it, it's often perceived as a negative performance measurement tool. They have to get over that mindset. As the post says " the Product Owner needs to know when the work on a story has gone over the original time estimated for the story. The Product Owner is concerned with Return On Investment... a legitimate reason to halt work on the story and reconsider the story’s business value." "if your team is spending 75% of their time doing testing then you might need t