Hacking: What it leads to.

Hacking is the way most programmers code. They combine random methods here and there in order to quickly finish the job at hand. And they can get away with it because the consumer does not care about what happens behind the scenes as long as the program does what it is suppose to do. Unfortunately this leads to spaghetti code. And spaghetti code is very hard to maintain as you can see from the above picture as things are mixed and matched all over the city in order get the code to up and running as quick as possible. So it becomes a huge hassle to upgrade or fix problems which leads to more hacks on top of hacks in order to keep the program working properly.

And so you should not hack your code together but take the time to think things through on a piece of paper. And by doing this, you will be able to come up will all the different types data structures you will need in order to make your project easier to maintain. The above image is a representation of this as your final project will fit together like a puzzle in which you can easily add or remove pieces to meet new goals that have been set by your client.

So in short hacks are good to get fast working prototypes or proof of concepts, however, in the long run one should strive to mapping out their data structures beforehand in order to improve maintainability of code.

OPEN SOURCE: Should you open source your project?

Open source basically means that "The program must include [its] source code... [or] there must be a well-publicized means of obtaining the source code fro no more than a reasonable reproduction cost preferably, downloading via the Internet without charge" (http://opensource.org/osd).

And I think that is a good thing as making your code open source has a ton of positive benefits.

1. When I make a project open source, people can help me out by submitting bug fixes.
2. People can improve my documentation since they are basing their documentation off of what they can see in my code, whereas my documentation may not make much sense since I know all of the components I'm dealing with inside and out.
3. People are more likely to trust running my program as others can verify it does what it says it does, or compile their own version from the source code to make sure the executable version I'm distributing matches up to the open sourced version. And this is especially true ever since the NSA (National Security Agency) was revealed to be using backdoors in closed source product like Facebook to have access to all of your information without you knowing about it.
4. If I decide to stop working on a project, people can take over maintaining it.
5. You can learn a ton of new things from reading other people's source code.

However, that does not go without saying there are some downsides to making your code open source.

1. People will steal your code and not give you credit.
2. People will compile your project with a modified name and charge money for your software even though you wanted to keep it free.

But in the end I still think that the positives outweigh the negatives as open sourcing a project means that it's safer program to run as people can verify that it does what it says it does and people can take over inactive projects to improve them to their heart's content.

AGILE: Yay or nay?

AGILE is a highly used method that many companies have used in handling the development process. It's manifesto is as follows:

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, we value the items on the left more.

And so basically what this means is that to have a better chance of succeeding in making a piece of software as a team, one should focus on the items on the left over the items on the right even though both items are important to the overall success of the project.

However, their methodology is bad on all accounts, as tools are a very important part of the process when building pieces of software as using an IDE's (Integrated Development Environment) breakpoint feature to process code one line at a time is very important to catch bugs that would have been very difficult to find using such as notepad.

Comprehensive documentation is also a huge necessity as people do not always stay in the same position. And thus the maintainer of the code changes around, and if there is poor documentation the resulting program will be a huge mess of hacks to piece everything together, whereas with properly documented code the new maintainers can easily understand how the program flows together.

Contract negotiation is also very important as that sets things in stone from the start so that one does not have to constantly rewrite things cause the customer forgot that they wanted to implement this feature or that one which they should have thought of earlier to save your team time from rewriting the program to allow such a feature.

And that relates to following a plan as it's set things in stone. This is good thing for the team creating the program as changing one thing that the customer may be simple may actually be a huger undertaking due to the approach the software team took in making the product before this new feature was requested to be included in the final product. 

And that's why AGILE's methodology in creating software is a poor one as it basically favors the customer who is paying for the program over the ones who have to poor sweat and blood into creating it, as it promotes the idea that the customer should be able to change willy nilly even though they should have explained everything clearly in the beginning so that the developers do not get headaches from having to change things up to satisfy the customer's new demands.