Agile non-negotiables are those software engineering practices that you'd be crazy to go without.
Unit Testing: Knowing your code works
Refactoring: Paying down your Technical Debt
Test-Driven Development: Knowing what your Goal is before Coding
Pair Programming: Tightly binding review and development together
Continuous Integration: Making it Production Ready
I'm a little crazy. I don't always use all of the above practices. I try to but my desire to be a hero and get things done quickly overcomes my sensible side. I think most people do this too. There are always outside influences that can seduce a developer into over promising.
The argument for ignoring those outside influences and always practicing the above agile non-negotibles is that you will have:
- better quality code,
- more consistent deliveries, and
- less bugs.
Stop worrying about taking three days to develop something that might have took two days had you left out unit testing or refactoring. That is only a short term savings. Consider how long it will take to fix a missed bug or add a new feature next year.
Using the above practices is an investment in the future of your software.
Jerry Yoakum's thoughts on software engineering and architecture from experience working with code, computer science, python, java, APIs, NASA, data mining, math, etc.
Wednesday, September 14, 2011
Sunday, September 11, 2011
Pair Programming
I'm a big fan of pair programming. I have used it many times and almost everytime the result was better code that was developed faster. Pair programming is like having continuous code review.
Sadly, there is a lot of controversy with this particular agile/XP practice. Seeing two valuable resources sitting down at one computer makes most managers nervous. They think their team's productivity has just been halved. The worst thing about this mentality is that it makes it clear that the manager thinks programming is just typing.
Mere typing, programming is not. A good idea or a bug caught early on in the process can save a team a lot of work and rework later. By pairing you share valuable knowledge and practices throughout the team, catching more bugs early, and increasing code quality.
Sadly, there is a lot of controversy with this particular agile/XP practice. Seeing two valuable resources sitting down at one computer makes most managers nervous. They think their team's productivity has just been halved. The worst thing about this mentality is that it makes it clear that the manager thinks programming is just typing.
Mere typing, programming is not. A good idea or a bug caught early on in the process can save a team a lot of work and rework later. By pairing you share valuable knowledge and practices throughout the team, catching more bugs early, and increasing code quality.
Monday, August 15, 2011
Merciless Refactoring
Many people are afraid to make code changes out of fear that they will break the code. To ensure you can safely make code changes you should change it often. I'm not talking about pointless changes but solid improvements. Run FindBugs against your code and fix the issues. If you disagree with FindBugs then use PMD or any static analysis tool. However, if static analysis suggests that your code looks like a bug then consider changing it to look less dangerous.
Anyway, the point of merciless refactoring is to always be improving your code. To make changes and ensure that it was easy to make those changes. If it isn't fast and easy then you need to make changes to make it fast and easy. Write unit tests, delete unused code, optimize loops, automate tests; everything you can do to make it possible to complete your next project in record time.
Merciless refactoring can also be described as following the boy scouts rule of always leaving a place cleaner than when you found it. If you add a method to a class then add some JavaDocs to the other methods while you're there. If you change a single line of code in a method, take a look at the entire class and fix it up if you can.
Anyway, the point of merciless refactoring is to always be improving your code. To make changes and ensure that it was easy to make those changes. If it isn't fast and easy then you need to make changes to make it fast and easy. Write unit tests, delete unused code, optimize loops, automate tests; everything you can do to make it possible to complete your next project in record time.
Merciless refactoring can also be described as following the boy scouts rule of always leaving a place cleaner than when you found it. If you add a method to a class then add some JavaDocs to the other methods while you're there. If you change a single line of code in a method, take a look at the entire class and fix it up if you can.
Labels:
coder,
computer-science,
Seattle
Location:
Seattle, WA, USA
Thursday, June 02, 2011
HIV/AIDS Cure Proof of Concept
New York magazine had this great article, "The Man Who Had HIV and Now Does Not", last month. It is as the title says about a man who was cured of HIV. It is an amazing read. It is not a cure for everyone; there are some specific genetics required but it is sparking new AIDS research.
Tuesday, November 23, 2010
Secret Santa
I wrote a little webapp to create secret Santa lists:
http://secret-santa-list.appspot.com/
It has a nifty feature that allows you to specify who to exclude as a possible choice for certain people when generating the list. In my case, I used it to generate a list for extended family where spouses did not get each other as secret Santas. Using the exclude list you could also set up a list to ensure that men get gifts for men and women get gifts for women.
For those who are concerned about sending the email addresses of their friends and family across the Internet there is a HTTPS link:
https://secret-santa-list.appspot.com/
http://secret-santa-list.appspot.com/
It has a nifty feature that allows you to specify who to exclude as a possible choice for certain people when generating the list. In my case, I used it to generate a list for extended family where spouses did not get each other as secret Santas. Using the exclude list you could also set up a list to ensure that men get gifts for men and women get gifts for women.
For those who are concerned about sending the email addresses of their friends and family across the Internet there is a HTTPS link:
https://secret-santa-list.appspot.com/
Tuesday, November 03, 2009
New Nutrition Goals for dailyburn.com
If you are not happy with dailyburn's suggested nutritional goals because you find them to be too heavy on protein and unrealistic for carbs then you might want to try calculating your goals based on the formulas below.
I've decided on a target of 1900 calories. Since I am not an the Atkins diet which dailyburn seems to be pimping I've done some of my own calculations to adjust my nutritional goal ranges.
First, I used dailyburn as a baseline writing down the suggested values and calculating the differences of each range. Second, I found recommended targets that I am happy with. Finally, I adjusted the values:
I've decided on a target of 1900 calories. Since I am not an the Atkins diet which dailyburn seems to be pimping I've done some of my own calculations to adjust my nutritional goal ranges.
First, I used dailyburn as a baseline writing down the suggested values and calculating the differences of each range. Second, I found recommended targets that I am happy with. Finally, I adjusted the values:
- With a target of 1900 I used the same range difference that dailyburn used, a difference of 250; giving me a range of 1775 - 2025.
- The carb target can be calculated by multipyling 0.125 times your target calories which gave me 238 g [1]. Using dailyburn's difference of 84 that gives me a range of 196 - 280.
- I used dailyburn's earlier suggestion to calculate the following ratio: 0.02613. Multiply that by your target calories to get your fat target. Using dailyburn's difference of 29 I get a range of 35 - 64.
- For an absolute minimum protein target you should calculate that off the USFDA's recommend value of 50 g per 2000 Cal [2]. I decided to use 1.5 times my weight in Kg as the upper limit; 152 [3]. Then using dailyburn's difference I got a range of 60 - 152.
[1] I picked this because it seems more realistic for my habits.
Saturday, October 24, 2009
Duracell donates emergency supplies to Springfield
I know that Springfield has had some bad storms but I never really felt in danger. I guess it is a bit riskier than I thought because Springfield is one of five cities recongized as vulnerable to power outages as a result of extreme weather. Apparently, Springfield and the surrounding 30 miles have the highest frequency of extreme weather-related damage reports in the nation. As part of Duracell's "Hours of Power" donation campaign, Springfield has received $100,000 of emergency products, including batteries, safety kits, chargers, and flashlights.
Some of the above information can be found at http://www.duracell.com/us/hoursofpower/cities.asp
Also, it is fairly clear that Duracell is using the donation campaign as marketing; which I am fine with, it is a business. Please take a minute and visit the site above and click on the donate button. It is a small effort to help others.
Sunday, October 04, 2009
Googlism
I just found http://www.googlism.com . It is an interesting waste of time for an individual but possibly a quick summary of a business' website.
Saturday, April 11, 2009
Banned CFC-driven Inhalers
In August 2008, Scientific American did a story about a federal ban on ozone-depleting chlorofluorocarbons (CFCs) to conform with the Clean Air Act. The albuterol inhalers without any CFCs cost three times more than generic inhalers that use CFCs. The CFCs from inhalers have an insignificant impact on the Ozone Layer but raising the cost of a $15 inhaler to $45 is a significant burden. I tried searching online but kept finding articles from last year. Does anyone know if this moronic switch has been enforced?
Wednesday, February 04, 2009
Data Mining Finds Bad Drugs
University of Minnesota Duluth professor Ted Pedersen and University Minnesota Twin Cities professor Serguei Pakhomov have been awarded a three-year, $935,000 National Institutes of Health research grant to develop natural-language processing (NLP) techniques that search through medical records to quickly detect widespread adverse drug reactions. Pedersen says the goal of the project is to improve the quality of post-marketing surveillance for adverse drug reactions. He notes that although the Food and Drug Administration approves all drugs before making them available, people often take so many drug combinations that it is not possible to test every interaction. Additionally, pharmaceutical companies may not have conducted enough studies to identify possible adverse reactions, he says. Pedersen will use NLP to develop methods that can identify different statements that have similar underlying meanings in medical records to enable the quick identification of patients who are taking similar combinations of drugs and possibly suffering from adverse reactions.
University of Minnesota Duluth (01/21/09) Latto, Susan Beasy
University of Minnesota Duluth (01/21/09) Latto, Susan Beasy
Subscribe to:
Posts (Atom)