Monday, February 20, 2017 4:22:50 PM
- Engineers tend to drive management decisions as their solutions tend to be represented precisely and mathematically.
- Do you have projects that may suffer from the butterfly effect?
- Always build software that can be easily reversed / undone. Think of decisions as being written on sand in a beach than in stone. There are NO final decisions.
- Tracer bullets are used in the military as their phosphorus leaves a trail that can help determine if they will hit the intended target. The idea is to use a similar approach for software to write code that glows in the dark.
- In a tracer code approach you write code that will be used in the final system and build out a complete architectural skeleton / framework that is not complete but works together. The developers will build on this over time. Tracer code is thus lean but complete.
- Prototyping on the other hand produces disposable code, with the aim of exploring specific aspects of the final system. Not all parts of the framework needs to be in place for prototyping. Once you learn from feedback, you start over from scratch.
- Don’t hesitate to use low tech solutions for quick and rapid prototyping such as whiteboards and Post-it notes. Always prototype any system that has risk.
Saturday, January 21, 2017 9:45:58 PM
- Make software that is orthogonal where the modules are independent and decoupled from each other. This way, changes in the interface do not need changes to the database. This leads to increased productivity and reduced risk.
- A helicopter is a classic example of a non-orthogonal system where all the four basic controls have to be operated together and are totally interdependent.
- Teams should be organized with minimum overlap and clear delineation of responsibilities. Orthogonality is also often referred to as modular or component based or layer based design.
- One good question to test orthogonality: if the requirements dramatically change, how many modules are effected? The MVC and Enterprise Java Beans (EJB) are good examples of orthogonal systems.
- To build such systems, do not rely on properties that you cannot control, write shy code where modules don’t reveal only whats necessary and don’t themselves rely heavily on other module implementations. Make an object change its state for you rather than you forcibly changing its state.
- Furthermore, avoid global data and instead explicitly pass any required context into the modules such as through parameters in OOP, use the singleton design pattern where you will ensure that there is only one object of a particular class which is a way to achieve the use of a global variable, constantly be critical of your code and refactor is often.
- Module level / unit testing is easier to perform than integration testing and should be part of the build process, during the unit testing process check how much of the rest of system needs to be included just to compile and link as a test of true orthogonality. As another idea, tag bug fixes when code is checked back in post testing and run monthly reports to see the number of source files effected by each bug fix.
Wednesday, January 4, 2017 10:08:25 PM
- Programmers are constantly in maintenance mode - fixing bugs and enhancing features.
- Avoid duplications at all cost - DO NOT REPEAT YOURSELF!
- Use code generators that works on metadata rather than re-writing structures that keep changing. The metadata will serve serve as the base to generate these structures across multiple languages.
- Good code reserves its comments only for the high level explanations. Bad code requires lot of comments. Remember every change requires updating both code and comments so keep it minimal. Avoid comments from becoming stale.
- Documentation and code both contain representation of the same knowledge and thats important to remember.
- Given a choice, replace static fields with dynamic fields that can be calculated based off changing values.
- For OOP based languages like Java and C++ always use accessor methods for reading and writing object attributes as it becomes easier to make future changes for caching etc.
- Y2K (Year 2000) fiasco was largely because developers were lazy to made the date size field parameterized or in some other cases lazy in implementing a centralized date service library.
- Developers should be in constant communication with each other to avoid code duplication and they should constantly read and review each others code / work.
- If it isn’t easy people won’t do it. Make it easy so that existing stuff can be reused as often as possible.
Monday, December 26, 2016 5:41:14 PM
- Produce "good enough" software that is acceptable by end users. Along with the scope make sure to ask your users what kind of quality they are expecting for their software. In other words, make quality part of the requirements process.
- In general, users will prefer great software today over perfect software tomorrow. Give your users something to play with early because their feedback will help you produce better software.
- Like artists who may overdo their paintings, programmers need to know when to stop. Let the code ship once its reached a “good enough” state.
- As a programmer, your knowledge and experience are your most important assets. To make sure these assets don’t expire -> Invest regularly in acquiring new knowledge and make this a habit, diversify your knowledge portfolio, try to learn an emerging technology before it becomes mainstream, review and rebalance your knowledge portfolio regularly.
- The more different things you know, the more valuable you are. The more technologies you are comfortable with, the easier it is to adopt to rapid change.
- Have broad goals to advance your technical knowledge -> learn at least one new programming language every year, read a technical book every month, take classes at your local college, participate in local user groups and don’t forget your local library is also a great resource.
- Question what you read and hear critically. There’s no need to accept everything that is presented to you. And remember, the more effective you are at communicating, the more influential you become.
Sunday, December 11, 2016 7:39:54 PM
- Pay attention to what you are doing while you are doing it and think of ways you can improve it. Question everything critically and continuously. Never run on auto pilot!
- At its simplest programming is about getting a computer to do what you want it to do.
- Document your work so that others can understand while engineer your work so that others can build on it.
- Be a good programmer by basing your core knowledge in the fundamentals of computer science and work on several real world project to gain experience.
- Contributing to an open source code base is an amazing way to develop vital skills of working with other people and understanding large scale project management.
- As a programmer, be open to new ideas and don’t be afraid to try out new tools / technologies. Be an early adopter.
- Software programmers are basically craftsman and we need care for our craft. There is no point in developing software unless you care about doing it well.
- Always ask yourself, how does this piece of code I am working on, fit into the bigger picture. Always, have the big picture in mind.
- Entropy is the amount of disorder in a system. It states that the disorder in the universe is always tending to a maximum. When this happens in software it is called “software rot”.
- Broken Window Theory: This is a fascinating theory that if in a neighborhood one small window is broken and not repaired then soon inhabitants will feel a sense of abandonment and other broken windows will appear and soon the entire community is destroyed. Likewise, in software fix the small stuff as and when they appear to keep out the big stuff.
- Don’t wait for big changes to happen. Don’t get caught up in permission and budget approvals. Build a prototype instead and show something tangible. People find it easier to join an ongoing success since they can see a glimpse of the future.