Codrin Andronic

"stop existing and start living" – M. Jackson

Software – Food Chain Analogy

Reading Code Complete 2nd edition, I came upon a good analogy for the software development process, which I will quote below.

Compare the software food chain to a real food chain. In an ecologically sound environment, seagulls eat fresh salmon. That’s nourishing to them because the salmon ate fresh herring, and they in turn ate fresh water bugs. The result is a healthy food chain. In programming, if you have healthy food at each stage in the food chain, the result is healthy code written by happy programmers.

In a polluted environment, the water bugs have been swimming in nuclear waste, the herring are contaminated by PCBs, and the salmon that eat the herring swam through oil spills. The seagulls are, unfortunately, at the end of the food chain, so they don’t eat just the oil in the bad salmon. They also eat the PCBs and the nuclear waste from the herring and the water bugs. In programming, if your requirements are contaminated, they contaminate the architecture, and the architecture in turn contaminates construction. This leads to grumpy, malnourished programmers and radioactive, polluted software that’s riddled with defects.

Let’s start eating healthy and build quality software once and for all!

Leave a comment »

MyGoals 1.3

New update availabe for MyGoals. Now it features a Vision Board and improved ergonomics.

Click HERE for download and details.

Leave a comment »

Pragmatic programmer tips

Recently I read an interesting book about software development  – “The Pragmatic Programmer, From Journeyman To Master“. I highly recommend it to all programmers. As a summary, following is a list with the highlights:

  • Invest regularly in your portfolio
  • Diversify your knowledge (the more things you know the more valuable you are)
  • Manage risk when investing in knowledge (are you learning useful things?)
  • Learn a new programming language every year
  • Read a technical book every few months
  • Experiment with different environment
  • Stay up to date with technical news
  • When you have something to communicate, make a plan
  • Know what to say
  • You must know the audience
  • Choose the right moment
  • Pay attention to aesthetics (if you write a document, or make a presentation)
  • Involve the audience
  • Listen
  • Provide answers
  • Do not duplicate (code, functionality, comments, anything)
  • Develop orthogonal (independent) systems
  • Develop closed components (do not let other components to change its state)
  • Use prototypes to try something experimental, such as:
    • Architecture
    • A new functionality into an existing system
    • The structure and content of external data
    • Component or 3rd party tools
    • Performance
    • UI / design
  • When you make a prototype, you can omit:
    • Correctness
    • Completeness
    • Robustness (error handling)
    • Style (comments, documentation, writing clean code etc.)
  • Implement your own mini-language when you need it
  • Do not panic
  • Always use source control
  • Learn a text manipulation language.
  • Use code generators
  • Write “shy” code – do not reveal too many details and do not interaction with many modules
  • Minimize coupling
  • When writing methods, use parameters of primary types
  • Develop configurable systems
  • Consider concurrency when you design
  • Always be aware of what you do
  • Developing something you don’t understand or working with technology that you are not familiar with is an invitation to make mistakes or wrong decisions
  • Work with a plan
  • Do not make assumptions. If you have to assume, consider the worst case
  • Document the assumptions and talks to them
  • Do not just test code, test assumptions too
  • Prioritize efforts and tasks
  • Do not let existing code dictate future code
  • Complexity of algorithms, in descending order of performance:
    • O (1) – access to array elements, simple instructions
    • O (log (n)) – binary search
    • O (n) – simple loops, computing min/max in arrays
    • O (n * log (n)) – quick sort, heap sort
    • O (n ^ 2) – two nested loops, selection and insertion sort
    • O (n ^ c) – combinatorial problems
  • Always test an algorithm for worst case before you start improving it (is it absolutely necessary, has it reached its limits?)
  • Consider refactoring in case of:
    • Duplications
    • Dependent components
    • Code that is expired due to modifications to the requirements
    • Bad performance
  • When you discover that something needs refactoring, acts immediately or as soon as possible
  • Don’t do refactoring and add functionality at the same time
  • Make sure you have rigorous tests before you begin refactoring
  • Take small steps and test often
  • Write code that is easy to test. Tests help to develop orthogonal systems
  • Test all possible input/output
  • Write tests before implementing
  • Unit tests illustrate how to use the module being tested
  • When gathering requirements for a project, spend time with users to better understand their needs
  • Use use-case diagrams when writing requirements documents
  • Do not overload requirements
  • Keep track of changes in the requirements
  • Use a glossary to identify clearly each term used in the project
  • In most cases, a problem seems more complicated than it actually is. Approach it systematically. Ask yourself the following questions:
    • Is there a simpler way?
    • Are you trying to solve the correct problem?
    • Why is it a problem?
    • What makes it so difficult?
    • Must it be done this way?
    • Is it needed?
  • Automate everything.
  • Generate documentation from comments in the code
  • Comments say what is implemented; they don’t explain how
  • Expectations should be communicated and exceeded only slightly
Leave a comment »

Winamp remote control

I just finished a small project for Pocket PC that is controlling Winamp music player remotely using Bluetooth or WiFi. It is free to use, just like my other software and quite useful, at least for me :)

Here is the link to Winamp Remote. Enjoy!

1 Comment »

Text User Interface

I have a passion for old things. The same is true for computers, software and programming languages. Lately I am nostalgic about the old days of MS-DOS, slow computers and TUIs (Text User Interfaces). I did a quick search on the web for TUI and it seems they are obsolete these days. Modern operating systems do not support it anymore. Linux is probably the only one that still supports it.  On windows platforms I think XP was the last to have support for TUI. Looking at software development tools, TUIs are not supported since a long time ago. Ok there is the option to build a Console Application on the .Net framework, but you can’t do anything more than read or write text.

Personally, I think TUIs could still be used today. It would provide a simple, intuitive and resource friendly way to interact with a system that does not require a very complex user interface. But I presume it’s just like everything else these days, why buy just one item when you can have 10 for the same price.

Leave a comment »