Archive | Uncategorized RSS feed for this section

Rockets before Rovers: The Agile Moon Landing Project

28 Jan

Brett W. Green's On the Contrary

When a pack of Software Engineers met in Utah in early 2001 to discuss a new way of building software, the summit did not produce a brand new SDLC, but rather a simple set of guidelines for software teams to follow in order to achieve better results with less friction. This ‘Agile Manifesto’ was as much a guiding force for future software development as it was an indictment of the processes that continue to plague the industry. As simple as the guidelines are, they can be profound when applied properly:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

That is, while there is value in the items on the right…

View original post 591 more words

Coding Kata: Practice Time for Programmers

4 Sep

Before I came to Fortigent, I spent two decades as a musician and educator.  Training for a career in music often starts


in elementary school.  I joined the school band, learned to read music and played an instrument.  I continued on through middle and high school.  I learned to practice, to perform in front of an audience, and to listen to music.  I continued through college, learning music history, music theory, and to teach music.  I started reading music educator’s magazines and blogs.  In my senior year, I spent months student teaching in a classroom with a master teacher, practicing everything I’d learned.  By the time I got to my own classroom, I didn’t feel completely prepared, but I’d had real, hands-on experience in a professional setting.


So how did I get from teaching music to being a software engineer at Fortigent?  I started programming text-based adventures in BASIC on my Commodore 64 as soon as I was tall enough to reach the programming manuals on my father’s bookshelf.  For years, I programmed little games or small applications, but didn’t actually decide to get a formal technical education until I was on maternity leave from teaching and had some time.

Going from music to programming was a bit of a shock.  I took classes, talked to my professors, did programming projects, and read blogs about software engineering.  This college experience was really different from the first, however.  ProjectThe two things that I really missed in the computer science degree were practice and that final student teaching-like internship.  I found myself a part-time, volunteer position with a videogame company as I entered my final stretch of college classes.  I learned a lot about teamwork, source control, and how to work and navigate in a large business application.  The other programmers were helpful, but I was still lacking the one-on-one experience that I’d gotten as a student teacher.  I also had not learned to practice.  At the time, I thought of the programming projects as practice, but those projects were nothing like the practice I had done as a musician.  There was no repetitive improvement or long term reflection on a set of exercises.

Soon after I got to Fortigent, someone gave me Bob Martin’s (usually known as Uncle Bob) book The Clean Coder.  As I read through the book, the chapter on practicing really hit home.  Uncle Bob wrote about how many software engineers never really learn to practice.  How can someone be a good programmer if they don’t know how to practice and don’t have a master teacher working closely with them?  “Perhaps the best way to acquire ‘Design Sense’ is to find someone who has it, put your fingers on top of theirs, put your eyeballs right behind theirs, and follow along as they design something.”  (  While I’ve been doing a little bit of this at work (the programmers here at Fortigent don’t seem at all shy about me standing over their shoulder asking questions while they program), this is not the same as programming what they are programming.

About a decade ago, programmers started talking about practicing.  Dave Thomas mentions sitting at his son’s karate lesson watching the children perform kata.  The students followed the movements of a master teacher and would perform these same movements at home as practice.  As Dave Thomas was watching the students learn their kata, he had been experimenting with a small coding exercise, doing it several different ways, trying to make it more efficient.  It hit him that a small exercise such as what he was doing was very similar to the practice movements the students were performing. ( Just as in Japanese martial arts kata, the purpose of a coding kata is to practice.  A coding kata is a small set of exercises that encourage trying out different combinations of coding techniques in a practice environment.

To me this feels like when I would go through a piece of music with my college trumpet teacher – he would play a line of music and I would play it back to him trying to get the same sound, inflections, and tone as he did.  As a software engineer, I have been going through the kata of the software engineering community, trying to get a feel for good programming.  Sometimes I will try an exercise on my own several times, seeing if I can improve upon my code each time.  Other times I will find a video of someone else doing the kata, so I can learn from how they program.

powerpointAt The Rockville .NET Group (RockNug) meeting on September 11, 2013, I will be sharing part of one kata I’ve found particularly useful, Roy Osherove’s String Calculator Kata.  I found it to be a great introduction to Test Driven Development.  I’ve watched several people’s online videos of the kata being done in several languages, using several unit testing frameworks.  I felt that his kata imparted to me the idea of working incrementally and solving problems as simply as possible.  As I worked through this kata, I read comments left by other readers, which really gave a sense of getting to hear what people were thinking while doing the kata.


I’ve been developing a sense of how to write tests before code, I’ve been learning to work incrementally, I’ve been learning to refactor my code, and I’ve been striving to think of simpler solutions to problems I encounter.  I’ve also been learning technology basics such as how to use a testing framework, keyboard shortcuts, and all the wonders of Resharper.  I have found several good resources and kata about refactoring legacy code, and this is where I plan to focus next.  I believe this will provide a good starting point for testing and refactoring legacy code that I will be working with shortly.

Data Obfuscation in MVC

30 May

Kolev Says...

Data obfuscation or de-identification is an interesting adventure to undertake. The problem initially disguises itself as being simple: “Give me data that is just as good as my production data; however, I don’t want anyone reverse the process or figure out what the original data was.” The simplest and perhaps a naive solution would be to just replace everything with a random set of characters. The data would certainly be obfuscated but would not be very useful.

As we begin the process, things like current application logic, industry legislation and standards, uniqueness of the data can be used to our advantage or works against us. The way data is used or travels through the application until it is shown to the user have considerable implementations to consider.

To illustrate the possible complexity, here are some examples:

  • No data-tier to the data source: An application that has no centralized data-tier…

View original post 626 more words

The coolest SQL Server function you never heard of

8 May

Brett W. Green's On the Contrary

Ever heard of the SQL_VARIANT_PROPERTY function? I didn’t think so.

SQL Server developers very often make the mistake of making their NUMERIC fields too large. When faced with a choice of how to size the column, they’ll often think “make it way larger than I need to be safe”.

This works OK as long as you simply store and read these values, but if you ever have to perform math with these columns, particularly some form of division or multiplication, you may find your results mysteriously losing precision.

This is because SQL Server can only store a maximum of 38 digits per number… if the results of your mathematic expression may yield a number larger than that, SQL Server will be forced to downsize it and remove digits from the mantissa as a result.

View original post 193 more words

21 Mar