Posts

Showing posts with the label software engineering

Battling the WhizKids: How I kept my website up in spite of the Prime Software Contractor

1999, the lead up to Y2K was a horrendous year for me. Too many long weeks, too much travel, tight deadlines, multiple competing projects, not enough sleep and a level of exhaustion that compromised my short-term memory and took around 5 years to mostly recover from... So at the end of 1999, when a long term friend, Peter, offered me a part-time contract looking after a few web-servers, it sounded like a doodle. Easy work, reasonable hours and good people to work with. What's not to like?!?! I got more 80+ hour weeks, a horror project and an exceedingly difficult Software supplier to work with. But because of my efforts, the site stayed up, remained usable and our area was the only part of the overall project to not make the papers (in a bad way). Apparently the project won a Gold Government Technology Award as well. I presented a paper on the Performance aspects at CMG-A and a presentation . All this and a very high-profile website: the first large-scale on-line Transaction of th...

What is Software? Why does it matter?

Software is the stuff that runs on computers. It's invisible, intangible and isn't even 'isomorphic': exactly one form for one thing . There's an infinite number of representations of a single function, program or thing,  producing the identical result. Computers are active cognitive processing engines . They can be electronic, mechanical, relays or "wetware" like brains. If you don't know what you're working on and with, then: You can't answer: What is it that we Do? Nor can you talk about:  What's the best way to do what we do? How do we assess results? Nor:  What is unique to what we do Professionally? What is the stuff that is ours alone? The wonderful Pamela Jones of Groklaw persuaded a very insightful Intellectual Property (I.P.) expert, Michael Risch, to contribute a piece: " Curing the Problem of Software Patents ". I attempted a contribution countering the notion that "Software is Mathematics" and it was lost i...

QUPSRSTCO: Software Design has more dimensions than 'Functionality'

Summary : There are multiple Essential Dimensions of Software Design besides " Functionality ". There are three Essential External Dimensions, {Function, Time, Money} and multiple Internal Dimensions. I'm ot sure where/how "Real-Time" is covered, it isn't just " Performance ": the necessary concurrency (not just "parallelism") and asynchronous events/processing require 10-100 times the cognitive capacity to deal with, and problems scale-up extraordinarily (faster than exponential) due to this added complexity. This is why Operating Systems and embedded critical systems (health/medicine, aerospace control, nuclear, Telecomms, Routers/Switches, Storage Devices, ...) are so difficult and expensive. Not understanding and enumerating these multiple Dimensions whilst seemingly teaching Functionality only is perhaps currently the single biggest single failure of the discipline of Software Engineering . The Necessary or Essential Dimensions ...

Why Microsoft is doomed to Commercial Failure.

Microsoft doesn't understand Software , or at least how to build it at-scale and the people who create it. All software and systems have a design life. As the world and platforms change, what was once a good design degrades. The classic example of "bit-rot" was "Y2K". The code and applications didn't change, but time showed up fundamental design limitations or flaws. Some organisations resolved the issue by setting the date back 28 years and "screen-scraping". It's a temporary solution that amplifies the point. On top of that, complexity is your enemy:  a lot of "undergrowth" develops over time and has to be cleared or it chokes the forest. Which means that at some point we all have to start again... [Hint: Apple did that with OS/X] A neat demonstration/proof comes from the world of Windows protocols:  SAMBA, a portable reimplementation of the Windows SMB protocol for "File and Print". The SAMBA team is up to its fourth comp...

I.T. Failure == Corporate Failure

Stephen Bartholomeusz writing in Business Spectator, 18 Nov 2009 , on the ASIC court case over the collapse of One.Tel. Bartholomeusz neatly summarises the root cause of the failure: Unhappily, its billing systems didn’t work, so it piled up debtors, while its competitors responded to the cut-price strategies. He goes on to say: While professing publicly that the group was on-track to be cash-positive..., internally One.Tel appears to have had little control or understanding of its cash flows or the mounting issues created by its billing system and finishes: Whatever Rich might claim, One.Tel wasn't a successful company, unless success is measured by revenue, not cash flows or execution. This is the first case I've noticed where the immediate cause of failure of a large, public company  has been it's I.T. systems. The root cause is poor management with an inability to execute - or to understand and control it's I.T. The field of "Software Engineering" is 40 ...

Mircosoft can't write O/S code

This cartoon lampoons Windows 7.0 Beta. Eerie. It underlines for me that Microsoft is crap at writing Operating Systems code. O/S's need to be correct, secure, robust (resilient to errors internal & hardware) first and foremost. Only after that look to features and 'performance'. How come the Great Unwashed, the home & business users and the media seem blinded in the same way the fanboi's are? Wikipedia's "Time Line of Operating Systems" underscores this point - compare Microsoft's offerings since 1999: Win-2000, Win-XP, Longhorn: abandoned, Vista and 'soon', Win-7. Compare to Annual or Biennial shipping of new releases OS/X, AIX, Solaris, HP/UX, Ubuntu, Red-Hat & Fedora, SuSE, ... Microsoft is the exception, not the rule. Everyone else in their class does better. Apologists for MSFT may add Win-98 SE, Win-ME, Win-server 2003/8, Media Centre, Home Server, Small Business Server and even Win-CE - plus the many 'Service Packs...

Alan Kay - History and Revolution in I.T.

Alan Kay invented Object Oriented Programming around 40 years ago with Smalltalk. Kay not only has a lot to say, his accomplishments lend him credibility. In 2003 he said: "our field is a field that's the next great 500-year idea after the printing press" The ACM awarded him its highest honour, The Turing Award , in 2003. The short Citation: For pioneering many of the ideas at the root of contemporary object-oriented programming languages, leading the team that developed Smalltalk, and for fundamental contributions to personal computing. Video of his 60min talk on the ACM site , and elsewhere, a transcript . The slides & demo used are not available. This 1982 talk for "Creative Think" brought this reporter reaction (the link is worth reading for the list of line-liners alone): Alan's speech was revelatory and was perhaps the most inspiring talk that I ever attended. This is my current favourite quote of Alan Kay's from Wikiquote: "Point of view...

Climbing out of the Ooze, or is that GNUze?

I've written on Microsoft heading for financial trouble and mounting internet security problems - but they have an underlying cause. Both ignore the hard-won Unix principle: Less is More . [the joke behind the pager, 'less'] This isn't just some arbitrary style choice, it's rooted deep in Computer Science and Software Engineering: smaller, cleaner interfaces - many fewer bugs if bugs/LOC is static (errors = LOC squared ) smaller code - potentially better understandability the Einstein principle: As simple as possible, but no simpler . Controlling system entropy - smaller code, less entropy to grow. Learning curve for new maintainers is lower - "cognitive span" of individuals not exceeded Learning curve for programmers lower and risk of errors of misunderstanding lower. More is Worse in Software Engineering - in every technical dimension. Microsoft has gone on to demonstrate that it is possible to have excessive 'customer features'. But this isn...

Human Response to Cognitive Workload

Context: This piece started as a question to a researcher in Psychology. There's a topic I've been trying to find research results for some time. I call it "(Human) Cognitive Response to Workload". There is a bunch of qualitative data for "Physiological response to Workload" available - e.g. US Navy for "stokers" working in different levels of heat. I found Prof. Lisanne Bainbridge in the UK. She's retired now. Her field is 'mental load' and couldn't point me at research in the area or help me properly phrase my question. She pointed me at Penny Sanderston, now Prof. at University of Queensland. What I'm interested in is any information to apply to Software Developers and other Knowledge workers: In the short, medium & longer term (day, week, year) how do you maximise cognitive output? What roles do sleep, recreation & holidays play in 'recharging' cognitive abilities? For different levels (degrees of difficul...

I.T. Failure - it's not about noticing and fixing the problems

Here's the deal: Commercial I.T. is generally poorly done - if only because it can't be proven otherwise. It's been that way for 50 years. Many people have attempted to define, measure and address these endemic problems - with very limited success. There are simple remedies, but the people who 'write the cheques' aren't implementing them. What's Going On? The problems with I.T. are not technical, nor within the industry. [It's not a 'profession' under any definition.] Something else is going on: it's outside I.T. - the "meta-level" - the people that employ and manage us... And it's been very consistent over time - provably for more than 40 yeras. And it's cross-cultural - every country was affected by "Y2K". It was foreseeable, completely avoidable, and at no additional cost, if remediation had been generally started around 1992. [There have been many, many "Clock Roll-overs" in the history of computin...