the Way of the code

the Way of the code

computer programming , a phylosophical approach

  • Technical debt

    • 17 May 2012
    • 0 Responses
    •  views
    • Edit
    • Delete
    • Tags
    • Autopost

    by Ward Cunningham

    OOPSLA '92
    Experience Report
    March 26, 1992
    The WyCash Portfolio Management System

    Another, more serious pitfall is the failure to consolidate. Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.

    Although the Author refers to an object-oriented upproach, this concept is considered to be general enough to apply in software developement as a whole. It is interesting that, the motto

    If it's not broken don't fix it 

    does not apply to software. 

    • Tweet
  • Software Rot

    • 27 Mar 2012
    • 0 Responses
    •  views
    • Edit
    • Delete
    • Tags
    • Autopost

    From the book

    ``Pragmatic Programmer, The: From Journeyman to Master"

    Andrew Hunt 
    David Thomas
    Publisher: Addison Wesley

     

    Software Entropy
    While software development is immune from almost all physical laws, entropy hits us hard. Entropy is a term from physics that refers to the amount of "disorder" in a system. Unfortunately, the laws of thermodynamics guarantee that the entropy in the universe tends toward a maximum. When disorder increases in software, programmers call it "software rot."


    There are many factors that can contribute to software rot. The most important one seems to be the psychology, or culture, at work on a project. Even if you are a team of one, your project's psychology can be a very delicate thing. Despite the best laid plans and the best people, a project can still experience ruin and decay during its lifetime. Yet there are other projects that, despite enormous difficulties and constant setbacks, successfully fight nature's tendency toward disorder and manage to come out pretty well.


    What makes the difference?


    In inner cities, some buildings are beautiful and clean, while others are rotting hulks. Why? Researchers in the field of crime and urban decay discovered a fascinating trigger mechanism, one that very quickly turns a clean, intact, inhabited building into a smashed and abandoned derelict.


    A broken window.


    One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment—a sense that the powers that be don't care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner's desire to fix it, and the sense of abandonment becomes reality.

    • Tweet
  • The separation of concerns

    • 12 May 2011
    • 0 Responses
    •  views
    • Edit
    • Delete
    • Tags
    • Autopost

     Edsger W. Dijkstra in his 1974 paper "On the role of scientific thought".

     

    Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained --on the contrary!-- by tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by "focusing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.

    • Tweet
  • The Nature of Software Development

    • 25 Mar 2011
    • 0 Responses
    •  views
    • Edit
    • Delete
    • Tags
    • Autopost

    The Nature of Software Development


    If software is not a product, then software development is not a product producing activity - it cannot be. If the true product is not the software but the knowledge contained in the software, then software development can only be a knowledge acquisition activity. True, we may consider some of the software development function to be a transcription of knowledge into the executable form. This is what coding is. However, coding is only one small part of the software development activity, and it is getting smaller. We can also reasonably assert that if we already have the knowledge, then transcribing it does not require much effort. The real work occurs when we try to transcribe our knowledge and find it is incomplete. The activity then quickly changes into a search for the correct knowledge.


    But software development is not usually viewed or managed as a knowledge acquisition activity. Most of our processes and our expectations in the software business are centered on the creation of a product (the delivered system). This is a quite logical view but it is also quite wrong. The creation of a functional system is not the product of the true activity of software development; it is the by-product of the activity of learning.


    This can be seen using a negative example: it is quite easy to deliver a system to the customer. The challenge is not to create a system but to create the correct system. If we know exactly what it is we have to do, we can create systems as fast as our fingers can type. The real challenge is finding out what the system should do, and how we can construct a system that does it. Once we have acquired this knowledge, the creation of the system is usually quite straightforward. Of course, once we (think we) have acquired the appropriate knowledge, and go ahead and build and test the system, we invariably find out there are things we did not know. This, of course, requires further knowledge acquisition.


    We can see this very clearly in the activity of testing systems. Testing of systems usually takes very little time - if we do not find out anything new. It is only in the uncovering of new knowledge that we take time. The purpose of testing is only partially to prove what we know. In reality, most of our time is spent finding out things we did not know.

     

    ..from the book

     

    The Laws of Software Process: A New Model for the Production and Management of Software
    Phillip G. Armour
    • Tweet
  • The Art of Programming

    • 20 Feb 2011
    • 0 Responses
    •  views
    • Edit
    • Delete
    • Tags
    • Autopost

    ..from the book

    C++ For Artists: The Art, Philosophy, and Science of Object-Oriented Programming
    by Rick Miller 

    The Art of Programming


    Programming is an art. Ask any programmer and they will agree — it takes a lot of creativity to solve problems with a computer. Creative people have an advantage in that they are not afraid to explore new avenues of design. Their open-mindedness and readiness to accept new ideas give them the ability to see problems differently from people who tend toward the cut and dry. This section offers a few suggestions on how you can stimulate your creativity.


    Don’t Start At The Computer


    Unless you have a good idea about what source code to write, sitting down at the computer first thing, without thinking through some design issues, is the worst mistake you can make. If you have ever suffered from writer’s block when writing a paper for class then you can begin to understand what you will experience if you begin your project at the computer.
    I recommend you forget the computer and go some place quiet and relaxing, with pen and paper, and draft a design document. It does not have to be big. Entire system designs can be sketched on the back of a napkin. The important thing is to have given some prior thought as to the design and structure of your program before you start coding.
    The location you choose to relax in is important. It should be someplace where you feel really comfortable. If you like quiet spaces then seek quiet spaces; if you like to watch people walk by and think of the world, then an outdoor cafe may be the place for you. Inside, outside, at the beach, on the ski slope, wherever you prefer.
    What you seek is the ability to let your mind grind away on the solution. Let your mind do the work. Writing code at the computer is a mechanical process. Formulating the solution is where real creativity is required, and is the part of the process that requires the most brainpower. Typing code is more like a drill on attention to detail.


    Inspiration Strikes At The Weirdest Time


    If you let your mind work on the problem it will offer its solution to you at the weirdest times. I solve most of my programming problems in my sleep. As a student I kept computers in the bedroom and would get up at all hours of the night to work on ideas that had popped into my head in a dream.
    Try to have something to write on close at hand at all times. A pad of paper and pen next to the toilet comes in handy! You can also use a small tape recorder, or digital memo recorder, or your personal digital assistant. Whatever means suit your style. Just be prepared. There’s nothing worse than the sinking feeling of having had the solution come to you in the middle of the night, or in the shower, or on the drive home from work or school, and say “I will remember that and write it down later,” only to forget it and have no clue what you were thinking when you do finally get something with which to record your ideas.

    ...


    Set The Mood


    When you have a good idea on how to proceed with entering source code you will want to set the proper programming mood.
    Location, Location, Location
    Locate your computer work area someplace that’s free from distraction. If you are single this may be easier than if you are married with children. If you live in a dorm or frat house good luck! Perhaps the computer lab is an alternative after all.
    Have your own room if possible, or at least your own corner of a larger room that is recognized as a quiet zone. Noise canceling headphones might help if you find yourself in this situation.
    Set rules. Let your friends and family know that when you are programming not to bother you. I know it sounds rude but when you get into the flow, which is discussed below, that is, if you ever get into the flow, you will be really upset when someone interrupts your train of thought to ask you about school lunch tomorrow or the location of the car keys. Establish the ground rules up front that say when it is a good time to disturb you when you are programming. The rule is - never!


    Concept Of The Flow


    Artists can really become absorbed in their work, not eating and ignoring personal hygiene for days, even weeks, at a time. Those who have experienced such periods of intense concentration and work describe it as a transcendental state where they have complete clarity of the finished product and tune out the world around them, living inside a cocoon of thought and energy.
    Programmers can get into the flow. I have achieved the flow. You can achieve the flow and when you do you will crave the feeling of the flow again. It is a good feeling, one of complete and utter understanding of what you are doing and where you are going with your source code. You can do amazing amounts of programming while in the flow.


    The Stages of Flow


    Like sleep, there are stages to the flow.

    • Getting Situated

    The first stage. You sit down at the computer and adjust your keyboard and stuff around you. Take a few deep breaths to help you relax. By now you should have a good idea of how to proceed with your coding. If not you shouldn’t be sitting at the computer.

    • Restlessness

    Second stage. You may find it difficult to clear your mind from the everyday thoughts that block your creativity and energy. Maybe you had a bad day at work, or a great day. Perhaps your spouse or significant other is being a complete jerk! Perhaps they’re treating you very good and you are wondering why?
    Close your eyes and breathe deep and regular. Clear your mind and think of nothing. It is hard to do but you can do it with practice. When you can clear your mind and free yourself from distracting thoughts you will find yourself ready to begin coding.

    • Settling In

    Now, your mind is clear. Non-productive thoughts are tucked neatly away. You begin to program. Line by line your program takes shape. You settle in and the clarity of your purpose takes hold and propels you forward.

    • Calm and Complete Focus

    You don’t notice it at first, but at some point between this and the previous stage you have slipped into a deeply relaxed state and are utterly focused on the task at hand. It is like reading a book and becoming completely absorbed. Someone can call your name but you will not notice, and not respond until they either shout at you or do something to break your concentration.
    You know you were in the flow, if only to a small degree, when being interrupted brings you out of this focused state and you feel agitated and have to settle in once again. If you avoid doing things like getting up from your chair for fear of breaking your concentration or losing your thought process then you are in the flow!


    Be Extreme


    Kent Beck, in his book “Extreme Programming Explained”, describes the joy of doing really good programming. The following programming cycle is synthesized from his extreme programming philosophy.
    The Programming Cycle

    • Plan

    Plan a little. Your project design should serve as a guide in your programming efforts. Your design should also be flexible and accommodate change, which means that as you program, you may make changes to the design.
    Essentially, you will want to design to the point where you have enough of the design to allow you to begin coding. The act of coding will soon reinforce your design decisions or detect fatal flaws that you must correct if you hope to have a polished, finished project.

    • Code

    Code a little. Write code in small, cohesive modules. A class or function at a time is good granularity.

    • Test

    Test a lot. Test each class, module or function separately or in whatever grouping makes sense. You will find yourself writing little programs on the side called test cases to test the code you have written. It is a good practice to get into. A test case is nothing more than a small little program you write and execute in order to test the functionality of some component or feature you have finished coding before integrating that component or feature into your project. The objective of testing is to break your code and correct its flaws before it has a chance to break your project in ways that are hard to detect.

    • Integrate

    Integrate often. Once you have a tested module of code, be it either a function or complete set of related classes, integrate these tested components into your project regularly. The objective of regular integration is to see if the newly integrated components break any previously integrated components. If they do then remove them from the project and fix the problem. If a newly integrated component does break something you may have discovered a design flaw or a previously unnoticed dependency between components. If this is the case then the next step in the programming cycle should be performed.

    • Factor

    Factor the design when possible. If you discover design flaws or ways to improve the design of your project you should factor the design to accommodate further development. An example of design factoring might be the migration of common elements from derived classes into the base class to take better advantage of code reuse.

    • Repeat

    Apply the programming cycle in a tight spiral fashion. You will quickly reach a point in your project where it all starts to come together, and very quickly so.


    The Programming Cycle Summarized


    Plan a little, code a little, test a lot, integrate often, factor the design when possible. Don’t Wait Until You Think You Are Finished Coding The Entire Project To Compile! Trying to write the entire program before compiling a single line of code is the most frequent mistake new programmers tend to make. The best advice I can offer is don’t do it! Use the programming cycle outlined above. Nothing will depress you more than seeing a million compiler errors scroll up the screen.


    A Helpful Trick: Stubbing


    Stubbing is a programmer’s trick you can use to speed development and avoid having to write a ton of code just to get something useful to compile. Stubbing is best illustrated by example.
    Say that your project requires you to display a text-based menu of program features on the screen. The user would then choose one of the menu items and press enter, thereby invoking that menu choice. What you would really like to do is write and test the menu display and choice functions without worrying about actually performing the indicated action. You can do exactly that with stubbing.
    A stubbed function is a function that exists to display a simple message to the screen saying in effect “Yep, the program works great up to this point. If it were actually implemented you’d be using this feature right now!”
    Stubbing is a great way to incrementally develop your project. Stubbing will change your life!


    Fix The First Compiler Error First


    OK. You compile some source code and it results in a slew of compiler errors. What should you do? I recommend you stay calm, take a deep breath, and fix the first compiler error first. Not the easiest compiler error, but the first compiler error. The reason is because the first error detected by the compiler, if fatal, will generate other compiler errors. Fix the first one first and you will generally find a lot of the other errors will also be resolved. If you pick an error from the middle of the pack and fix it, you may introduce more errors into your source code! Fix the first error first!

    • Tweet
  • About


    638 Views
  • Archive

    • 2012 (2)
      • May (1)
      • March (1)
    • 2011 (3)
      • May (1)
      • March (1)
      • February (1)

    Get Updates

    Subscribe via RSS