All it takes is a little communication

Back in action again with another posting.  My activity on this blog slowed down over the summer months as I focused on work and relaxing - probably a little more on the relaxing side.  Now it's time to  get back in the groove and start sharing again.  For those of you that have been reading this blog for a while, I hope you enjoy the new contributions!  And for those of you seeing this for the first time welcome - I'm attempting to share my thoughts and opinions on the software development process and the roles that people play.  My hope is that everyone reading through these articles can take away something that helps them, and that through the messages that I receive, that I learn something along the way.

In many of my past entries I've discussed various issues that can cause a project to go off the rails.  This could be anything from a minor irritation within the overall lifecycle, or it could be more significant causing a reevaluation of the overall project.  Obviously, I'd much rather deal with the former vs the latter, but as with anything in real life, we don't always get to choose the trials that we face.  And, sometimes we learn the most as we fight through the fire.

One of the things that I'd like to tackle in this particular discussion is the need for true open and honest communications between all members of the team.  Many times, an issue that surfaces within the overall project is the culmination of the effect of someone not getting out of their seat and talking with a team member.  Ok, getting out of your seat may not be the right terminology in today's connected and distributed world.  Team members have many options to connect with other team members - email, instant messaging, video conferencing, texting and - wait for it - good old fashioned face to face discussions.

Let's be honest with each other - how many times have we all been irritated and wanted to pull our hair out because the response we get from someone when it hit the fan was, "Well, that's what I was told to do.", or "That's what the design said to do."  In most instances I then ask the team member, "But you knew that wouldn't work, right?"  And in most instances I'll hear them admit that they knew the design was wrong or that the item in question had been overlooked or that they didn't feel that they could discuss it with someone else on the team.

To be clear, this is an example and the point of this post is not to lay blame for all issues at the feet of the requirements or design teams.  In many instances, the people doing the requirements and/or design work don't necessarily understand all of the fine details of how the system is plugged together. Understanding the fine technical underpinnings of the system is the responsibility of the technical teams.

If someone, anyone, on the project team identifies that something is missing, incomplete or just not right, it is their responsibility to get it corrected.  By whatever means are necessary.  It is not proper to sit on the issue and knowingly let your teammates head down a false path, or to let the project stall.  If you're truly on the team, you're invested in making the team, the project and the company successful in creating solutions that can be used by your customers. The key phrase, "you're invested"!  If you're invested in the idea, then that means you're taking it personally to make sure that it's right and that the end result exceeds expectations.

How difficult is it to poke your head up from what it is your doing to have a conversation?  Not every issue requires a meeting with 10 people in the room looking for various options and contingencies.  Take a stab at solving the issue on your own with a few key people.  Review your thoughts with key individuals on your team and then make it happen - get it corrected and resolve the issue before it has time to fester and become a potential roadblock to the project.  If you can't get to the bottom of it and find a reasonable solution, then work with the Project Manager to get a larger team of individuals to together to work through the issue.  Oh, and by the way, make sure you're keeping the Project Manager in the loop on what you've found - that doesn't mean they need to take control of the situation, it just means you're keeping them informed.  In fact you can tell them upfront: I don't need you to get involved.  I'm working through some options right now with a couple of people, if we can't find a solution by the end of the day, then I'll need you to step in and assist with coordinating a larger part of the team to help find a solution.

As I've said in past postings, people are messy.  We all make mistakes from time to time.  Maybe when putting the design document together I forget that a certain data element needs to be replicated to another application in the enterprise.  By forgetting to include this in the overall design, I have inadvertently introduced a situation that may impact the companies ability to bill for certain services or maybe the information won't show properly to the customer service representative answering customer calls.  In either case, the mistake was small, but the impact to the customer is real and measurable.  

If down the line, one of the software engineers notices that I overlooked documenting how the data element needs to be replicated between systems - it isn't the end of the world.  A quick call to confirm that "not replicating" the data wasn't an intentional decision and in fact was a mistake - allows the project to proceed.  Documents can quickly be updated and the change communicated to the rest of the team.  However, if the software engineer sees the mistake, doesn't say a word and we get all the way in to production without replicating the data, we have negatively impacted our customer by potentially billing improperly for services or by delaying assistance when they call in for help.

Look, one of the reasons we are all in the jobs that we are in, is to solve problems.  Sometimes that means sitting at your desk and doing what's in the job description.  However, in today's world, the job description is just the start of what you really do in your job.  You've also been hired to be part of a team!  It means removing the small roadblocks before they become big roadblocks.  It means uncovering and resolving those inconsistencies before they can be seen by the customer.  It means finding ways to work with others to provide the unexpected.  It means noticing that your teammate is stuck and helping find a way around the obstacle.  It means thinking through something that you believe is wrong - validating the assumption, and then working with the team to provide a solution before the issue has a chance to delay the project, increase costs or call in to question the need to finish the project.

Today, we are hyper-connected.  Take advantage of the tools that you have to break down barriers and talk with those around you to solve problems.  I don't want you to think that your job is to just satisfy the "requirements" or "design documents".  I want you to challenge those things that you think are wrong or that negatively impact the customer and work with others on the team to identify solutions that allow the project to move forward and meet or beat the timeline, reduce the overall effort and provide a superior solution.

Tags: SDLC, Software Development Lifecycle,  Project Lifecycle, Project, Manager, Development, Paradigm, Security, Secure Development Lifecycle, Communication

For more information on David L. Collison: LinkedIn Profile
 

Back to Security - Ignore and You'll Pay

Def Con 21 kicks off this week, so I thought it would be an appropriate time to swing our discussions back to the topic of security.  In some instances, repetition of a theme can become stale. Security is one topic where you must always pay attention and never, ever drop your guard.

Leading up to Def Con 21, white hat researchers have announced that they have figured out how to hack into both the Ford and Toyota automotive systems.  They have announced that they will release a 100 page report detailing their efforts.  While they will not release the specifics of how they achieved the takeover, now that they've reported it can be done, you can bet that others will follow suit.  According to reports, the researchers were able to force a Prius into suddenly slamming on the brakes while the car was moving 80 mph, they were also able to force the steering wheel to jerk and force the engine to race unexpectedly.  On the Ford Escape system, they were able to disengage the breaks on the vehicle while it was moving at low speeds.

Additionally, academic researchers have also figured out how the anti-theft systems of several automotive makers can be bypassed.  Volkswagen, Porsches, Audis, Bentleys, and Lamborghinis are all subject to the hack.  The researchers claim that they have figured out multiple ways to bypass the immobilizer mechanism by reverse engineering the algorithm.  Volkswagen actually preemptively went to the courts and received an injunction preventing the authors from publishing the details of their research.  While the judge has prevented the information from being published, now that it is known that it is possible to hack the algorithm, others will undoubtedly follow and perform their own research.

Earlier this year, a tool called "DropSmack" was created by a security consultant that used DropBox to remotely take over a PC.  The consultant was able to add macros to a Word document on DropBox and then use spearfishing techniques to get an executive at a company that he was working for to open the said document.  Once the document was open, the consultant was then able to take over the PC.

How many of you work in organizations that either knowingly or unknowingly have PC's that are connected to DropBox?

As altruistic as we would like to be, we live in a society where some people are intent on gaining access to systems that they don't own for various reasons.  Sometimes they just want the thrill of being able to gain access to something that they shouldn't have access to; sometimes they want to take everything you've got.  If you're not paying attention and doing the right things to secure your network, secure the applications you use and secure the applications you create internally, you're making it easy for the bad guys.  The latest report from Verizon - the 2012 Verizon Data Breach Investigations Report - identifies that 78% of all attacks last year, were targets of opportunity.

As you are designing software, the primary question you need to ask yourself is, how will someone attempt to use this to do something that they shouldn't be doing?

Security needs to be a significant focus of the design, build and test phases of the lifecycle.  Additionally, regular testing needs to occur once your applications move in to the production environment to ensure that the system is not vulnerable to the latest vulnerabilities.

I've heard some organizations make the claim that they can't afford to take the time to worry about this, that they are small and nobody is going to notice their web site.  Well, I hate to be the one to burst your bubble, but if your network is accessible via the internet - and who's isn't these days - then you're at risk.  If you don't take the time and dollars necessary to secure your web site and put the technology in place to protect your network, someone is going to find you.  They may not necessarily be looking for you, but they will find you.  They have built tools that move through the internet going from one system to the next looking for vulnerabilities.

If you haven't patched the software you've purchased to run your systems, and kept those patches up to date - then they will find it.  If you haven't patched the open source software you are using, and kept those patches up to date - they will find the opening.  If you haven't prevented cross-site scripting from impacting your web site, if you haven't prevented SQL injection - then they will find it.  There are easy things you can do to protect yourself and not all of it costs money:

1. Keep your systems patched to the most recent releases - whether purchased or open source.
2. Install firewalls in your network and keep the firewall patched to prevent unauthorized programs from accessing your network.
3. Institute and enforce policies for users to change their passwords regularly and to use strong passwords.
4. Install and use anti-virus/anti-malware/anti-spyware protection.
5. Don't open emails from people you don't know?
6. Institute whitelisting of applications and internet sites that can be used and accessed from within your organization.

From a development standpoint - if you're not familiar with OWASP, then you need to hit their web site and immediately begin to pay attention to the vulnerabilities that they report.  This site identifies the most common vulnerabilities impacting web sites.  They explain the vulnerability and recommend what you can do to prevent these types of attacks on your network.  I'm not saying that this is the be all and end all of security, but this site at least points you in the right direction.

You also need to ensure that your developers take the time necessary to educate themselves on secure development techniques.  This isn't an overnight miracle that will suddenly make you invulnerable, it is a process that will take time, but will slowly and surely improve the security stance of your applications.  They are books, websites and seminars dedicated to this topic.  Pick the one you can afford and get moving - today!

Tags: SDLC, Software Development Lifecycle,  Project Lifecycle, Project, Manager, Development, Paradigm, Security, Secure Development Lifecycle

For more information on David L. Collison: LinkedIn Profile