tag:blogger.com,1999:blog-72218324388438574232024-02-19T22:56:20.848-08:00Rob Robason on Technology and Science<p>I believe it's important to occasionally share my opinions on current topics related to science and technology. I don't expect everyone, or even most people, to agree with me - but hey, it's a free country, and the things I post here are sincere and deserving of your respect for my right to say them.</p>Rob Robasonhttp://www.blogger.com/profile/07193917057529728647noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-7221832438843857423.post-31574671199902631122016-03-07T23:56:00.002-08:002016-03-07T23:56:40.185-08:00Why we should all oppose the Federal government's attempts to force Apple to decrypt the San Bernardino iPhoneMany of you may not remember, but back in 1993, in the early days of encryption technology on the Internet, the NSA attempted to foist upon the people of the U.S. the now forgotten "<i>Clipper Chip</i>." The proposal was essentially to require, by federal law, all encryption to be performed using an integrated circuit designed by the NSA. The chip's design was a secret, but would have a built in back door - a secret key held by the government - that could be used to decrypt any secrets. The chip would be required to be included in every new computer. It would be unlawful to encrypt data by any other means. The NSA tried to sneak this through Congress, but an alert security community in private industry caught on to the maneuver and, through a campaign waged largely on what was known as Usenet, managed to raise awareness and the idea met with such resistance from the tech community - including a vocal part of the fledgling UNIX community - that eventually the effort lost momentum.<br />
<br />
Besides the obvious concern about misuse by the federal government, another reason the chip met resistance was that few people believed the government could do as good a job at encryption with a closed design as with an open one. Encryption algorithms of the day were rampant, and many were found to be flawed.<br />
<br />
Another concern was many doubted the government's ability to keep such a secret key secret. One need only recall cases of espionage of the era. And for a modern example one need look no further than Edward Snowden, One of the biggest risks of stolen encryption keys and broken algorithms is that once broken, everything that's been encrypted - <i>ever </i>- using that algorithm can then be easily decrypted. This means that secure communications could be recorded and later decrypted - with huge potential consequences.<br />
<br />
Unfortunately, government, including ours, doesn't have an exactly stellar record of safeguarding our privacy. Law enforcement especially, is especially prone to a willingness to do anything to "get their man", especially without determined and careful oversight. Our founding fathers observed this in the British government, and went to great lengths to ensure that our citizenry wouldn't be subject to such abuses. This was the foundation for the fourth amendment to the U.S. Constitution:<br />
<br />
<blockquote class="tr_bq">
Amendment IV</blockquote>
<blockquote class="tr_bq">
The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no warrants shall issue, but upon probable cause, supported by oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.</blockquote>
It seems to me to be absolutely self-serving and short-sighted that any branch of our government should be so selectively blind as to deny that encryption is a <i>reaction</i> of the people to breeches of the promise that we should be "secure in [our] persons, houses, papers, and effects". But I think law enforcement today is guilty of exactly that - the arguments that I hear boil down to an attitude that people don't have a right to keep secrets from the government. Recent, and not so recent, revelations about the government's intrusions into our "papers and effects" only reinforces long held suspicions of many, and has bred distrust in many who were previously naively trusting of government reassurances.<br />
<br />
Mind you, I'm very supportive of law enforcement and want them to catch the bad guys. I don't want terrorists to succeed in attacking our rights and peace and sovereignty. Terrorism is nasty business. But so is a government spying on its people. I'm not willing to give up my rights to my own privacy as a law abiding citizen, and don't think that it's in our best interest as a nation to follow blindly a government that has proven itself so willing to intrude into so much of our personal lives.<br />
<br />
I think Apple has taken the right stand, and applaud them and the other tech companies who have also spoken up. But I think we as individual citizens need to stand up and speak out against the progressive erosion of our right to privacy. After all, the rights we're talking about here are <i>personal</i> rights.Rob Robasonhttp://www.blogger.com/profile/07193917057529728647noreply@blogger.com0tag:blogger.com,1999:blog-7221832438843857423.post-85985103954152693182014-01-30T16:27:00.001-08:002014-01-30T16:27:52.536-08:00Setting the Project Gantt time scale - overcoming ZoomOne of the things I hate about Project is the Zoom function on the Gantt view. As it is, zooming leaves the scale in weird units on seemingly arbitrary boundaries. Given that, I wish it would zoom on the task table and leave the Gantt time scale alone. Frustrated with this, I wrote the following macro to easily reset the timescale to something sensible: showing 3 tiers with year, quarter, and month in a compact format. You may find this useful directly, or may want to play around with the constants to customize it.<br />
<br />
<span style="font-family: "Courier New", Courier, monospace; font-size: x-small;">Sub YQM_timescale()<br />' Changes the Gantt scale to show Year, Quarter, and Month<br /> TimescaleEdit TierCount:=3, Separator:=True, Enlarge:=80, _<br /> TopUnits:=pjTimescaleYears, TopLabel:=pjYear_yyyy, TopCount:=1, _<br /> TopAlign:=pjCenter, _<br /> MajorUnits:=pjTimescaleQuarters, MajorLabel:=pjQuarter_Qq, MajorCount:=1, _<br /> MajorUseFY:=True, MajorAlign:=pjCenter, _<br /> MinorUnits:=pjTimescaleMonths, MinorLabel:=pjMonth_m, MinorCount:=1, _<br /> MinorUseFY:=True, MinorTicks:=True<br />End Sub</span>Rob Robasonhttp://www.blogger.com/profile/07193917057529728647noreply@blogger.com0tag:blogger.com,1999:blog-7221832438843857423.post-44374683277420548912014-01-30T16:11:00.000-08:002014-01-30T16:31:07.418-08:00Collapsing Project Summary Tasks that are 100% CompleteHere's a little VBA macro I wrote to toggle the collapse/expansion of Summary tasks that are complete. This can be useful as you move through the project and want to easily hide the clutter of completed work.<br />
<br />
<span style="font-family: "Courier New", Courier, monospace; font-size: x-small;">Sub collapseCompletedSummaryTasks()<br />' Toggles visibility into subtasks of completed summary tasks<br /> Static collapsed As Boolean<br /> Dim t<br /> <br /> If collapsed Then<br /> collapsed = False<br /> Else<br /> collapsed = True<br /> End If<br /> <br /> For Each t In ActiveProject.Tasks<br /> If t.Summary And t.PercentComplete = 100 Then<br /> If collapsed Then<br /> t.OutlineHideSubTasks<br /> Else<br /> t.OutlineShowSubTasks<br /> End If<br /> End If<br /> Next t<br />End Sub</span>Rob Robasonhttp://www.blogger.com/profile/07193917057529728647noreply@blogger.com0tag:blogger.com,1999:blog-7221832438843857423.post-9665829133439260322014-01-30T16:05:00.000-08:002014-01-30T16:05:40.230-08:00More on Project Management - Microsoft Project, specificallyOver the past year and a half, I've been deeply intrenched in using MS Project on a couple of projects for which I've been the designated scheduler. While this has been great experience, I've learned that Project can't do a whole lot of things that I expected of it. Rather than whine about it, I've written a number of macros using Visual Basic for Applications to help me out. I thought that I'd dedicate some postings to sharing some of the solutions I've developed. I'll try to keep my griping about Project to a minimum, but will describe what I am trying to accomplish and have found to be lacking as I describe my solution.Rob Robasonhttp://www.blogger.com/profile/07193917057529728647noreply@blogger.com0tag:blogger.com,1999:blog-7221832438843857423.post-5636673717460725442011-06-03T17:00:00.000-07:002011-06-03T17:16:17.785-07:00Project Management Professional (PMP)I've been preparing for the Project Management Institute's PMP certification exam. Although I had scanned the PMBOK in the past, this preparation has forced me to do some deep thinking about the PM processes and related methodologies like the CMMI, Scrum, and Lean Six Sigma.<br />
<br />
Since the PMP is industry neutral, I expected little attention to many of the processes I thought unique to software. My first discovery was that these processes (things like configuration management and requirements management) were heavily emphasized.<br />
<br />
With the CMMI, if you do things straight out of the model, you're assured a successful SCAMPI appraisal. The PMP is different in several ways (besides of course that it's a personal certification):<br />
<ol><li> There's no assurance that a complete mastery of the PMBOK will result in success on the exam. PMI expects PMPs will have a level of wisdom, experience, and judgment that goes well beyond the PMBOK, and warns that questions on the exam may derive from many other non-PMI sources.</li>
<li>The exam demands a deep understanding of, and experience in, project management. Many gray areas are covered that would thwart a novice PM or "poser". </li>
<li>Even after becoming certified, you can easily have your certification stripped. The PMI's standards of conduct require, beyond the usual ethical behavior, that members (i.e. PMPs) report to them a PMP who doesn't have the required experience or competence. And they put teeth in that: Awareness of, and failure to report to the PMI, can result in having your own certification stripped!</li>
</ol>For me, it's the need for deep understanding that has driven me to a much more thoughtful review of the underlying principles of project management than ever before. This, in turn, has lead me to much richer development as a project manager than I ever expected. I understand much more of the interconnectedness of PM and project activities, and of the why behind them.<br />
<br />
I've been a software process engineer for years, but preparing for this exam has caused me to see that models such as CMMI must be integrated with disciplined project management to really achieve it's goals. In fact, I would say that if a organization was weak in process, their first step should be to require all of their PMs to maintain a PMP certification. It's inevitable then that a focus on improvement will follow, and aforementioned methodologies I will achieve their potential, and be applied for the right reasons!Rob Robasonhttp://www.blogger.com/profile/07193917057529728647noreply@blogger.com0tag:blogger.com,1999:blog-7221832438843857423.post-37779182727399109362009-01-19T08:38:00.000-08:002009-01-19T08:52:31.832-08:00Lean, Six-Sigma, and so forthI recently began training to become a Six Sigma Black Belt. The training also includes Lean topics ala Lean-Sigma. I'm pretty impressed with the potential here - though there's nothing really new to speak of.<br /><br />The greatest benefit of Lean is that it draws attention to a common problem with process improvement initiatives, especially those driven by models such as CMMI and ISO 9000: the creation of onerous overhead that often offsets the gains. Lean looks for waste - and is severe in its definition - forcing careful consideration of everything that's done.<br /><br />In fact, Lean captures some of the essence of Agile methods, inasmuch as these are an attempt to cut through the red tape and quickly produce a quality product. One could legitimately claim that Agile Methodology is a result of Lean thinking, whether or not the formal methods of Lean were used to derive it.<br /><br />It's no paradox that the phrase "Lean and Agile" escapes the tongue with such ease, because the physical attributes represented by these metaphorical terms are naturally connected.Rob Robasonhttp://www.blogger.com/profile/07193917057529728647noreply@blogger.com0tag:blogger.com,1999:blog-7221832438843857423.post-20519897033783494952007-09-13T10:38:00.000-07:002008-02-27T09:01:40.442-08:00Waterfall vs. Agile Development<span style="font-weight: bold;font-family:arial;font-size:130%;" >Waterfall vs. Agile Development</span><br />Criticism of the waterfall model of software development is in vogue these days, while the relative benefits of agile methods are extolled - with the primary assertion being that "requirements are unknowable" and continually evolving, and must be learned by progressive discovery through trial and error.<br /><br />I assert that <span style="font-weight: bold;">the value proposition of agile methodology has nothing to do with evolutionary requirements discovery, and everything to do with listening carefully to the customer and building a better understanding of their needs</span>.<br /><br />Agile proponents postulate that fully understanding requirements is impossible, holding up failures of the past as anecdotal evidence. The conclusion has been that the lifecycle model is at the root of these failures. It's more tolerable to blame the lifecycle model than confess a lack of knowledge, skill and discipline in eliciting requirements.<br /><br />The real success of agile - that many have missed - is the subtle insertion of frequent validation of developer assumptions with users. It is this novel concept of actually listening to the user that is the real key to success in agile. But frequent validation was not invented with agile methods - and has been a mainstay of successful software projects from the beginning.<br /><br />The <span style="font-style: italic;">reality</span> is that, although we live in a very turbulent time, business needs actually evolve rather slowly. And while there are some technologies that are evolving rapidly, most software is developed for more "mature" needs.<br /><br /><span style="font-weight: bold;">A</span><span style="font-weight: bold;">t the same time agile is reveling in the spotlight, a quiet revolution is taking place</span> in thoughtful, lean-thinking software companies. They are targeting poor requirements practices as a source of waste, and are <span style="font-weight: bold;">focusing on proactive discovery of users needs as the solution</span>. This approach differs from agile in one important way: it recognizes that requirements are not as hopelessly volatile as suggested by agile/anti-waterfall extremists - that requirements volatility is more an effect of evolving understanding of user needs, than of changes in them.<br /><br />A major source of methods in this space is an unlikely, but logical, discipline: human factors - not the UI designers focused on layouts and widgets, but the psychologists who look at the systems within which humans interaction with computer systems. ACM's SIGCHI is common ground for many of these folks.<br /><br />One method in this space with which I've had incredible personal success is called Contextual Design. It teaches developers to learn how system users think about their work. One of its activities, Contextual Inquiry, puts software developers in the cubicles of prospective customers to observe, understand, and record the details of the work. What they learn is taken back and shared with the development team. One of the most remarkable things about Contextual Inquiry has been its effectiveness and efficiency in building the deep understanding needed by developers to make informed day-to-day design decisions. This is a huge leap past the practice, shared by traditional and agile methods, of unwittingly depending upon erroneous personal assumptions about the users' world.<br /><br />Other elements of Contextual Design provide efficient up-front validation at critical decision points along the way that minimize waste, an approach to definition and construction of incremental releases, each contributing recognizable customer value.<br /><br />Instead of spending energy on variations and iterations on the agile theme, developers need to focus on learning and applying new skills to capture and share a more robust understanding of the environment and work of targeted users. If we did that, we'd be developing more relevant software with less waste and more profit. And we'd be having a lot more fun doing it.Rob Robasonhttp://www.blogger.com/profile/07193917057529728647noreply@blogger.com2