In my last post, I touched on security a little bit from the perspective of the client, the company and more interestingly, the developer. I wanted to elaborate more on this idea in terms of what we as developers are responsible for when it comes to making design decisions, especially when it involves introducing potential vulnerabilities.
Hopefully most of us are at a minimum, mildly security conscious, at least to the point of not INTENTIONALLY introducing vulnerabilities into a system. However, as I discussed in my previous post about RSA, sometimes decisions are made to *supposedly* intentionally design insecurities into a system. What kinds of things do we as developers have to consider when designing such systems?
When we are responsible for the implementation of systems with the potential to effect billions of people what's important? Is it the money? Insuring people that are dependent on them are shielded
from failures? Does anything matter? Should we live in anarchy?
While money is definitely important, at the end of the day, I'd definitely prefer to go home to an average home and drive an average car if it meant I was able to sleep at night knowing that I wasn't contributing (HOPEFULLY!) to the unabashed mass surveillance of practically the entire planet! So for me, I
think designing something with the utmost skepticism for anyone that may potentially use it and also for the people that write my checks (HOPEFULLY! HA that's two) is the best way to ensure that as little collateral damage as possible is incurred. To me, it's more important* to know the things that I build weren't designed to harm them than it is to collect a few extra bucks that I'll probably blow on beer.
At the vary least, it wasn't intentionally. Not that that is not much of a reassurance to clients and employers, but at least I'll be able to sleep at night knowing I didn't sell out.
* I hope I'll be singing this tune 20 years from now but what am I, a fortune teller?
Wednesday, January 29, 2014
Tuesday, January 28, 2014
Preliminary Timeline
The following just a preliminary schedule for the Carbon Counter 5000 project. As such, it does not take into consideration any kind of development and maintenance that would normally occur in a real world development environment.
Having said that, one of the design goals from the beginning will be to develop a system that is highly maintainable there by allowing for a potentially higher return on investment for the investors. A real project would definitely take long term issues like maintainability into account when developing a large system and this projects aims to reflect this practice.
Having said that, one of the design goals from the beginning will be to develop a system that is highly maintainable there by allowing for a potentially higher return on investment for the investors. A real project would definitely take long term issues like maintainability into account when developing a large system and this projects aims to reflect this practice.
Sunday, January 26, 2014
Client confidence
One thing that is obviously very important for any company to succeed is the customers' and stakeholders' confidence in the company they will be interacting with. Things that disrupt these relationships can have dramatic effects on the future success or failure of the company in question and software development is no different.
I personally, find security very interesting. When looked at security from a consumer point of view, if a product is insecure or perceived to be, obviously customer confidence becomes an issue. If it becomes such an issue as to be made public and/or widely discussed the confidence of investors and share holders in the company can become a real issue.
A division of EMC that recently came under fire was RSA. Edward Snowden disclosed information implicating RSA in creating software that used insure encryption functions by default on some of it's products. The NSA purportedly paid RSA 10 million dollars to build these insecurities into their products.
When this was made public it had several harmful implications for EMC. The first is obviously that consumer confidence in RSA was shaken. This was observed when several (8) security professionals boycotted the 2013 RSA Conference[Source].
The fact that this news has been made so public, at least in the security community, means EMC/RSA
now face a real problem with their stakeholders' confidence in the financial integrity of their investment since customer confidence has been effected by Snowden's disclosure.
So far we have looked at this issue from the stand point of the client side; the consumers of the software, and the people investing money in the company. One issue that is just as valid but maybe not considered as often is the point of view of the company and the developers that implemented the software. What kinds of things does one have to consider when actually implementing a system with respect to the consumer. What kinds of responsibilities do we as developers owe a client when making a software system. What kinds of ethics does the developer need to consider when working on non-trivial systems in the real world? Is it more important to have listen to the boss and just add the "feature" (vulnerability) or does one go against this in the better interest of the end user?
This is an interesting topic that is common to many disciplines, not just software engineering but we as developers stand in a unique position as we are ultimately the ones responsible for these decisions. In my next post, I plan to delve a bit more into this topic to really discuss the kinds of issues that a developer is responsible. I might touch on the topics like the difference between the open source versus proprietary paradigm.
I personally, find security very interesting. When looked at security from a consumer point of view, if a product is insecure or perceived to be, obviously customer confidence becomes an issue. If it becomes such an issue as to be made public and/or widely discussed the confidence of investors and share holders in the company can become a real issue.
A division of EMC that recently came under fire was RSA. Edward Snowden disclosed information implicating RSA in creating software that used insure encryption functions by default on some of it's products. The NSA purportedly paid RSA 10 million dollars to build these insecurities into their products.
When this was made public it had several harmful implications for EMC. The first is obviously that consumer confidence in RSA was shaken. This was observed when several (8) security professionals boycotted the 2013 RSA Conference[Source].
The fact that this news has been made so public, at least in the security community, means EMC/RSA
now face a real problem with their stakeholders' confidence in the financial integrity of their investment since customer confidence has been effected by Snowden's disclosure.
So far we have looked at this issue from the stand point of the client side; the consumers of the software, and the people investing money in the company. One issue that is just as valid but maybe not considered as often is the point of view of the company and the developers that implemented the software. What kinds of things does one have to consider when actually implementing a system with respect to the consumer. What kinds of responsibilities do we as developers owe a client when making a software system. What kinds of ethics does the developer need to consider when working on non-trivial systems in the real world? Is it more important to have listen to the boss and just add the "feature" (vulnerability) or does one go against this in the better interest of the end user?
This is an interesting topic that is common to many disciplines, not just software engineering but we as developers stand in a unique position as we are ultimately the ones responsible for these decisions. In my next post, I plan to delve a bit more into this topic to really discuss the kinds of issues that a developer is responsible. I might touch on the topics like the difference between the open source versus proprietary paradigm.
Saturday, January 25, 2014
Carbon Counter 5000
In deciding on what would make an
interesting software project, the first question you have to ask
yourself is this, "what do people need?"
Clearly, people love games, but that's
been done to hell and back so from a creativity stand point, not an
original idea at all. This leads to the next question, "What is
an original idea?"
The real problem with answering this
question is that if you can think of it, chances are someone has done
it. What you really have to do then, is come up with something that
may not sound completely origin at a high level but, when viewed more closely, reveals a rich exposure of features that serve novel purposes.
Taking these things into consideration,
I came up with something akin to a calorie counter. The difference
here is that instead of counting calories, this application allows
people to track their carbon emissions. Much like the calorie
counter, this application could be used to help people track exactly
how big their carbon footprint is and
offer advice on how to adjust it to levels that could help to prevent
environmental damage.
In doing research on the originality of
my idea, I decided to use summon the Oracle (Google) in order to see
if there was anything similar. To my surprise NO ONE has thought of
this!!! Just kidding, BP actually has an web-based application that
will estimate your carbon footprint. However, they didn't
appear to offer any kind of long term
tracking of carbon emissions for users.
After realizing that this kind of
functionality wasn't offered I thought, "Wow! that really could
be cool actually!" Not only does this application have the
potential to be fun to implement, it also allows for a bit of
originality in terms of the kinds of feature that could be offered as
well as being well within the realm of possibility to implement under
the given constraints (time mainly). It also, is designed with
helping the environment in mind so not only is it original and
interesting, it also has the potential to "change the world",
which is very much in the spirit of software engineering as defined
by Prof. Ackley.
So without further ado, I present to
you, Carbon Counter 5000*. An interactive web based application
that allows users to not only track their carbon emissions, but also
gives them feed back on ways to improve / minimize their footprint.
Users can sign up to have on going carbon tracking as well as
anonymous emissions analysis, if a user doesn't want to share
information.
* The 5000 in the title
doesn't mean anything, I just added it because everything sounds more
exciting if you put a big number at the end.
Wednesday, January 22, 2014
What is Software Engineering?
Having become a relatively new initiate to computer programming ( about 2 years ago was when I started), I have really only started on the journey of professional software development. Before it was function this and for loop that; now it's all "what library has the stuff I need?" and "does this fit into some kind of design pattern." This doesn't even begin to touch on all the aspects of software development and as a starter, a more fundamental question must be asked: What is software engineering?
In sticking with our initial assignment, I read the Wikipedia article on software engineering to get a feel for what it's all about and to get my brain ready for what should be a fun semester (hopefully not too much crying on my part!).
To paraphrase Dave on the first day of class, Software Engineering is the design of software to change the world. (not sure if actual paraphrase or actual quote -___-)
On the one hand, this definition carries quite a bit of weight. "Change the world" is a phrase that wont soon be forgotten and, looking back on when I first started college and even now, part of me wants very much to change the world and I think that if a poll were taken, most college students and more broadly, people in general would love to contribute something that would change the world. While this thought is nice, to me it seems a bit incomplete.
The incompleteness I feel stems from the fact that we as people are inherently selfish and so when someone says, "You can change the world" (or something to that effect), we automatically assume that it's going to be only us that does the changing. In reality, society is huge and complicated and much like a watch, takes more than just one gear to function correctly. Much like the gears of a watch, the people that make up the software development team must work together. Even Bill Gates and Steve Jobs, who most lay-men would accredit computers to, worked with other people.
Wikipedia defines software engineering several ways, one of which is as follows:
"The application of systematic, disciplined, quantifiable approach to the development, operation, and
maintenance of software".
This definition, while less inspirational than Dave's definition, does seem to have a bit more of the engineering flavor to it, but is still lacking an emphasis on the importance of cooperation between individuals to achieve a common goal that would be otherwise nearly impossible if attempted alone.
To this end, my working definition of software engineering is as follows:
The cooperative application of engineering principals towards software that can change the world.
In sticking with our initial assignment, I read the Wikipedia article on software engineering to get a feel for what it's all about and to get my brain ready for what should be a fun semester (hopefully not too much crying on my part!).
To paraphrase Dave on the first day of class, Software Engineering is the design of software to change the world. (not sure if actual paraphrase or actual quote -___-)
On the one hand, this definition carries quite a bit of weight. "Change the world" is a phrase that wont soon be forgotten and, looking back on when I first started college and even now, part of me wants very much to change the world and I think that if a poll were taken, most college students and more broadly, people in general would love to contribute something that would change the world. While this thought is nice, to me it seems a bit incomplete.
The incompleteness I feel stems from the fact that we as people are inherently selfish and so when someone says, "You can change the world" (or something to that effect), we automatically assume that it's going to be only us that does the changing. In reality, society is huge and complicated and much like a watch, takes more than just one gear to function correctly. Much like the gears of a watch, the people that make up the software development team must work together. Even Bill Gates and Steve Jobs, who most lay-men would accredit computers to, worked with other people.
Wikipedia defines software engineering several ways, one of which is as follows:
"The application of systematic, disciplined, quantifiable approach to the development, operation, and
maintenance of software".
This definition, while less inspirational than Dave's definition, does seem to have a bit more of the engineering flavor to it, but is still lacking an emphasis on the importance of cooperation between individuals to achieve a common goal that would be otherwise nearly impossible if attempted alone.
To this end, my working definition of software engineering is as follows:
The cooperative application of engineering principals towards software that can change the world.
Subscribe to:
Posts (Atom)