Book Review - "Don't Make Me Think" by Steve Krug

I love to develop software. That is one of the places where I can find my "tov." One aspect of software development that always bothered me was my belief that I could not excel at all areas of the software development life cycle. Let me explain...

Toosl for the job: UML Artifacts, and other Techniques I Always Carry

To understand an existing system or a problem domain one needs to break it apart into smaller pieces. UML Artifacts have been my tool of choice for decomposing a system or understanding a business problem and designing a solution to address the issues that come up.

The UML Artifacts I commonly use in almost daily basis include:

Test the quality of your assumptions as you analyze, design, code, test and deploy/ship your next app.

As you prepare to tackle a new project, you probably make sure all the proverbial IT ducks are in a row.  From skills sets, tools in both hardware and software, environments, connections... the list seems endless at times.  You always make sure to acquire the highest quality of tools and skill sets that your budget can buy. Have you ever considered to inspect the value or the quality of your assumptions as you step into a new project? Failure to keep assumptions in check may lead us to have faith in pursuing a goal of oversimplification, or worse, believing in a myth!

Simple Cost Benefit Analysis for the Software Developer

I took some college courses about finance a few years back. Little did I know that the knowledge I acquired during those sessions was going to become handy during a discussion about the best course of action on a project we were reviewing. In this case, the conversation went something like this:

We need to add functionality "x". If / when we do this our application will perform much better and it would clean up our design. 

But the cost to analyze, design, code, and test would be very expensive. You know development hours are expensive! How about we "throw more hardware" at the problem?

It has got to be cheaper than coding it right. Besides, we do not want to over engineer something if we don't have to. Right?