Constant project failure changes nothing
The only constant is change. The only lesson learnt from history is nothing is learnt from history. The only lesson learnt from failed IT projects is ......what? The only constant is change?
16 posts • joined 29 Jul 2007
There's a shortage of skilled, talented, and honourable executives and directors going by the evidence of this SCO affair.
I do feel for the other employees of the company. I wish they could all resign en bloc and find a company that has good leaders. Ah, good and true leadership, does it exist?
I've just had a peek at the SCO website and particularly the jobs page:
And look at this: sco.com/images/company/SCO_Code_of_Conduct_and_Ethics_Policy-Final.pdf
Is the placement of any files on your computer property without your knowledge breaking any UK law?
If so, then why has not any person taken them to court?
If so, then why have not any of our elected representatives taken action?
If not, then we must have a law that unambiguously requires that any commercial software must come with accessible documentation that describes any communication, and the reason for it, with any device external to the computer that the software is installed on and that the user has the option to stop said communication.
"the updated framework will enable developers to build and deliver more flexible, loosely coupled web services applications, says the supplier."
At what total accountable cost?
"The contract-first approach"
"lenient XML processing."
"transition to Web Services development straightforward."
Transition and development was and is straight forward?
"has produced an online tutorial to explain the contract-first approach."
Mumbo fucking mumjo!
I fervently hope developers have such a faculty as critical thinking!
Lest the sale and marketing people are correct in their assumptions about developers!
"age-old criticism of UML (okay, one of them) that the diagrams become out-of-date as soon as you begin coding."
It must be assumed that a developer or software engineer creating a UML diagram is designing. The end product of this activity is called a design. So what the criticism is really about is that the design becomes out of date as soon as someone starts coding.
In my experience it is more that designs are just ignored if or when their existence comes to light. Why?
1. The 'design' is just a drawing usually consisting of square boxes with lines joining them.
2. The coder looking at the design just sees a drawing consisting of square boxes with lines joining them.
And do not forget that a UML diagram can represent an analysis model as well as a design model.
I have been using Enterprise Architect since 3.6. It's a very good quality product and I vote for it with my money. I do not use it for database design; for this I use relational theory and ER diagramming etc.
"One of the big challenges in today's complex environment is getting software done in some close relation to the schedule."
A bigger challenge is to estimate the effort required to achieve a goal to a reasonable degree. The assumption in the above quote is that the schedule, which is an estimate, is the independent variable and that the actual required effort, 'getting the software done', is the dependent variable.
In a majority of reports and surveys addressing the issue of unsuccessful IT projects, a significant factor was the unrealistic estimates given.
As you you say, just knowing where a problem is, is half of the battle. Getting to grips with estimating required effort and resources is a major strategical objective in the project planning war.
"there is still the issue of building applications and services in an easy and timely fashion."
You don't say!
Note: assume software applications and software services.
Does any one person who has rudimentary knowledge pertaining to the specification, design and construction of software believe that there will be a time when human beings will not have an issue with this problem?
When this problem becomes 'easy' human programmers and human software engineers will not be required. We will be in Westworld or Foundation.
A program listing is a document that represents a software design. Compilers and linkers actually build software designs.
A program listing is a set of machine readable instructions written in a 'computer language'.
If a program listing is in C++, Java, C# et al is a design so is a listing of assembler instructions whether it has been written by a human or been disassembled from an anonymous binary.
So a hex dump of a binary in a text editor is a design?
So using Jack Reeves 'suggestion' we can conclude that:
The compiler and linker are only translating one representation of a design into another representation of the same design.
If a UML model representation of a design is a machine readable design document that can be directly translated to what a CPU can process then the MDA brigade have reached home.
It is so easy!
All that is required to 'really understand' a subject is to read a paper.
is that the the first thing they learn is the syntax of the code language that they have blindly chosen to learn programming. It is also a solo effort; there's you and that infernal machine and may be a reference manual and a third-party book on the language competing for real-estate on your desk with the half-full cup of scummy cold tea and biscuit remnants. This all done in an evolutionary fashion. Design is, at this juncture, an amoeba lurking around the now itinerant programmer's mental ecology waiting a natural event to force it to evolve and become a significant factor in the survivability of our programmer. These natural events are always hard lessons.
A natural event may be the program not behaving as expected.
Is this natural event sufficient to nudge our shy amoeba to greater to complexity? Nope. Our programmer takes a sideways evolutionary step and debugs.
Debugging, the lazy and/or inept programmer's way of (not?) designing software.
Hey I like this thinks the hobbyist programmer, I'll go get a degree in Computer Science.
The programmer gets one.
The programmer now finds a job. Their line manager has given them a task which is to write code that fulfils a certain requirement, namely get this done by a so-and-so deadline. As an aside I've never met a line that is truly dead; nor have I seen a definition of this term in a business book.
So our heroic programmer writes the code and debugs as was custom as a hobbyist and as it seems to work it gets released in to that wild and unstable tribe callously named 'the users'. The line manager is pleased - I'm a good manager as I got the product out on time. He notes that he will be able to go to that programmer and ask for more of the same. The programmer obliges reinforcing the not too distinct instinct that this is how programming is done in the professional arena. The programmer gets a promotion of analyst/programmer or more pretentiously software engineer. What about that degree. learning all that so called life-cycle stuff, requirements, specifications, designs and testing? Transform analysis? Formal methods? Collar and tie job! This company seems to think it all expensive nonsense.
So what was the purpose of all that effort for my degree?
In time the programmer gets bored or more likely cynical, stressed and pissed-off.
I'm off to further my career and more money. The programmer goes to another company having gone through a most diabolical regime of IT recruitment agencies and interviews. The interview for this company included IQ test(s), coding test(s) answering questions from programmers, managers and HR people. They must be a really good company to work for to be so careful in their hiring process and I passed it! It's a good job they didn't ask about design and all that! I was a bit taken aback when they said they didn't have source control software though, when I asked about it. Must have some other great method.
The programmer sits down at their new, posh desk and starts to look at the product code. Their jaw mimics a snake's in the process of swallowing a pig. Their eyes widen in a helpless attempt to compensate for the fact that the 90cm monitor cannot widen in same manner to show a function in all its obesity even in a 2-point font. 600 lines?
After a few hours more of such an exciting and exhilarating journey the programmer then shout's to no one in particular - "Who wrote this crap?! Where's the design?!"
The amoeba stirs.
What is a design? Is it the product of designing? What is designing? What is the purpose of designing and the design?
Is code a design? Aha! The programmer's brain, latching on to this straw with all its coding and debugging might, says yes. The amoeba goes to sleep again. All is well.
The confusion starts with the customer. Most customers are unsure of what they require to and how to express any requirement precisely and accurately to any third party.
In theory the customer writes the functional requirements; what a system is required to do. There will be a general high-level requirement that may be functionally decomposed to lower-level requirements and so-on until a level of detail is arrived at which is considered appropriate for an analyst to work on.
A use case may be used to model a certain functional requirement at an appropriate level of detail. This can be useful to the designer and the manager of the software solution. The designer will have a start in perceiving some structure to the software solution and the manager will have a start in visualising a block of work and hence to begin formulating resource needs, creating milestones, perceiving traceability dependencies etcetera.
A use case is also a set of use-case scenarios. A use-case scenario that is actually written is a particular instance from the set of use-case scenarios that is the use case. The particular, written use-case scenario has been written to describe the interaction between a system and an entity using that system with an explicit or implicit reference to a functional requirement and at the same level of detail as that functional requirement.
This implies that unambiguous use cases follow from unambiguous functional requirements.
I take with a pinch of salt and large dose of scepticism any assertion that anything is key to understanding a complex problem.
Except may be, critical thought.
"C) IT as an integral function of the business This is characterised by an "us" or "we" mentality which has the business and IT objectives integral to each other indistinguishable. There may or may not be an IT director in place, but if there is, they are more of a business person than a technical one."
And just what does "they are more of a business person than a technical one" mean? It is just a platitude.
"The obvious starting point is to ask what an IT director of a large organisation does"
Is it? I do not think so. The starting point is to ask a company what the IT director's duties and responsibilities are. Then ask what the IT director does.
"given the fact that most businesses' fortunes are now inextricably linked to their IT capabilities"
Yes. I would mention first that all businesses' fortunes are inextricably linked to the information deemed necessary to those businesses to survive.
And who should be responsible for this information in a company?
What companies require first is a director of information not an IT director.
Go to any (large?) company and ask; is there a board-level member that is responsible to the company for the timely gathering of, production of, transformation of, assessment of, accessibility of and storage of information?
Technology is just a set of tools that can be applied to the domain of information.
Gilbert: The great thing about a tool, if deployed and used correctly, is it promotes discipline.
Wrong. That is definitely putting the cart before the horse, facing each other. The horse is the discipline, the tool is the cart. Without a horse no cart is going anywhere.
A tool used correctly implies that there are rules in the use of that tool which are followed by people that are trained to use it within those rules. If a trained person does not follow those rules then that person exhibits ill-discipline. If the owning authority of those rules does not exert discipline then there is no authority, no discipline.
A tool should make it it easier for a person to follow those rules; this is not saying the tool is making it easier for the person to be disciplined.
The jargon-fest of evolution again? The theory of biological evolution applied to a field of IT . I despair! The theory of tradition applied to a field of IT. I despair!
Do these nonsensical forced analogies-cum-paradigms actually help an individual involved in solving problems?
I'll use use whatever that is to hand to help me analyse the problem domain, to understand the problem domain and to lead me to a practical solution to any particular problem of that domain. One of the most problematic problems is being aware of what is to hand. Another is evolving an awareness of how you yourself learn.
The theory of tradition - I do not have to think.
The theory of evolution - unpredictable small changes, unpredictable big changes - the change may have a chance of having a future.
Tradition and evolution have one thing in common; no analysis.
I find myself agreeing (mostly) with Brian Miller again. Although I would like him to give a few examples of his 'horrific languages".
Er, I've used a goto in a compiled as C++ program. I'm not religious about this or any other aspect of coding.
I wonder what Brian thinks of AOP? The new paradigm for solving all of software's ills. It can be applied to every aspect of software production. One aspect that it is applied currently to some frameworks is the the garbage collector. The garbage collector, odd term don't you think? Makes one wonder about the term 'garbage in - garbage out'. Now on a two weekly collection.
Now then, where are we supposed to put the braces?
"A unit test is a test of behaviour (normally functional) whose success or failure is wholly determined by the correctness of the test and the correctness of the unit under test."
This says that the unit test is a test of verification - build the product right. Cannot not a unit test be a validation test - build the right product?
I agree with Brian Miller's comment. When I began learning software engineering nearly 2 decades ago I seem to remember there were five significant basic activities that could be discerned that a person or group of people went through during the production of a software product.
1. Formulation of Requirements from the analysis of answers to questions asked of people/users
2. Formulation of Specifications from the analysis of requirements
3. Design(s) from the analysis of the specifications
4. Design implementation from the analysis of the design(s)
5. Testing - validation and verification - according to the analysis of requirements, specs, and design.
These are have always been interleaved and bi-directionally communicating activities.
I have seen very little evidence of these activities during my career in software.
Is an assertion in code a test? A test of validation? A test of verification?
Biting the hand that feeds IT © 1998–2022