This has been in my in-box for a while. It’s still good.
The reason for Windows used to be MS-Office. Now, the reason for Windows is Windows. Large parts of Corporate IT can’t afford to do anything other than pay Microsoft whatever it wants. With the failure of Vista, those days may be winding to a close.
Things change. It’s hard to keep up. Sometimes the changes surprise me. Other times I get a flat spot from banging my head against the wall.
A few links to universal truths of software development.
One of the standard lies is the “Cone of Uncertainty”. At inception, we don’t know the total cost; but we’ll get better at projecting the cost. At some point in the future, we’ll predict with perfect accuracy. Bunk. Total Bunk. But, customers love to hear it, so we repeat it. With charts.
If 80% to 90% of the IT budget is spent keeping the lights on, where does that leave technology innovation? In the hands of vendors.
A common problem with corporate IT is that “Learning” is given the pejorative label “Failure” and reviled. Go ahead, have a good idea. Now, fabricate some ROI numbers to justify it. The next step is usually an enterprise-scale effort which involves so much effort that course changes are impossible. Any lesson learned will require canceling a huge project, and calling your fabricated ROI numbers into question. Your good idea will now be described as “We tried that before and it didn’t work.”
Perhaps there are alternatives.
For decades, I’ve been trying to position technology to support a business model. It’s what we’re told to do. Consultants help customers support their business with appropriate technology. I just realized how fundamentally wrong that is.
Recently had a fight with a manager on the Technical Debt issue. The conversation has shifted focus, so I may have made my point. There’s a certain amount of “As Cheap As Possible” still floating about, though.
My experience is wholly bad. Open source has the “taint” – it ain’t Microsoft or Oracle or Java, so we can’t use it.
I was asked about using UML to depict an relational database. Superficially, the question is senseless. The answer would be the two syllable “Du-uh.” However, when someone asks, it means there is confusion or politics concealing the real problem.
See Joel on Software, Evidence Based Scheduling . Interesting points, in some respects. Rehashes of old advice from another point of view. In particular, the question of having to do design before estimating was raised as a possible problem with Joel’s approach.
This is a real “aha!” moment that reveals The Big Issue with management decision-making. This explains the endless CYA management, and it gives some hints at how to put rationality into the process.
It’s not surprising that new development feels more productive than maintenance. I wonder if it really is?
Cool quote from Charles Babcock in “Three Scenarios For How Microsoft’s Open Source Threat Could End ” in the May 21st Information Week. Is it really true? Are services overtaking software?
I think that the analysis is flawed, and that leads me to a fourth, and more likely, scenario.
Test Data Generation is a tangential part of reverse engineering. Reverse engineering is the first step in building enhanced application functionality. After reverse engineering comes the forward engineering and the new database design.
As part of every database design, you must have a specific performance model, and you must do performance testing early and often to meet the performance objectives. This means doing performance analysis and tuning before the application software is written.
You’ll need a Mock Application and Mock Data to explore your database design. For this, you need Python.
In part 3 , we started looking at SQL embedded in C. We wrestled with typedef, the CPP and the SQL precompiler. Having put that into some kind of order, we can now look at parsing C source, and building a function cross-reference.
The SQL embedded in C edition. In this posting, we’ll work through the preliminaries of parsing Embedded SQL, the C Preprocessor and C itself. In another posting, we’ll move on to gathering cross-reference information from the C source.
The client has a stored procedure that doesn’t do the right thing. What would it cost to fix it? The situation spins out of control and turns into a reverse engineering problem for which Python is the solution.
Here’s the issue: It’s Strategic – but it’s not – but it was – now it’s a burden . The customer calls and asks me for an estimate to maintain, adapt, upgrade or replace some piece of legacy software. Unless it’s a trivial exercise (2,000 lines of code or less), I can’t just “look at it” to see what the effort is. I need to analyze it, and my analysis tool of choice is Python.
Yes, this is a recurring theme.
Yes, I see a drive toward complete self-destruction of the IT capacity of an enterprise. Indeed, it almost seems inevitable that an IT organization should wind up in a position where they are unable to deliver anything other than basic infrastructure. I see three phase transitions in this death-march to insignificance. And, I think I have better approach.
In “Project Justification ”, I wrung my hands over justifying a rewrite. I missed an element broadly termed “risk”. Here’s why. In this revision, I try again to clarify some definitions.
Chad Fowler is starting a series “The Big Rewrite ”. Also, see CodeCraft, “To Rewrite or not to rewrite, that is the question ”. Principally, these are about planning and executing a rewrite of core software. I’ve bumped into this, also, and have a number of questions.
Here’s MS’s new Fear, Uncertainty ad Doubt (FUD) message: “If it ain’t SUSE, you could be SUED.” The alternative is “Don’t get SUED – get SUSE! ”.
See “Vista’s EULA Product Activation Worries ” by Mark Rasch for weird new twist in lawsuits.
Which is it? We write or customize in-house software because we need unique features – features that must be of some strategic value. Then we never touch that software again to make any improvements or design changes. What changed? Why is it no longer strategic once it’s in production?
The BBC reports today that Google is entering the software market. How will they attack the herd mentality that makes Micro$oft so successful?
100% test coverage, while an admirable goal, isn’t the whole story in testing. Things can still fall through the cracks, and tools don’t help much.
Yes, there is a root cause of turnover. No, it’s not ambition or greed. It’s a kind of shoddy management that’s best described as Failure to Focus™.
See Open Source Software: Who Gives And Who Takes? in Information Week, May 15th. The asymmetry between open source author’s and beneficiaries is nicely described.
Hobbit says “Everything in the windows world does not directly work with the “rapidly-evolving” windows api’s (for example, c# devs rarely concern themselves with api calls.) If there is such a lack of clarity in these API’s causing a “barrier to innovation,” why is windows still the easiest and most popular platform to develop on?”
First, there’s a distinction being emphasized here, between application programming (in C#, apart from low-level API’s) and platform programming (where the low-level API’s matter more).
It could be simply that I watch the LAMP community more closely than the Windows community.
“I would ask a previous question: Is now the time get ready to support open source ? As a business, you don’t want to get too far ahead of your customers.” [link ]
What? Are you saying IT is like lawn care?
When we are confronted with a problem that is – clearly – solved by an open source product, what next? How do we make the business case?
Many people are uncomfortable with open source. We have to get past the silly discomfort issues – which surface in many strange comments – and move into the real nuts and bolts of cost and benefit.
CP tells me from time to time that he “just can’t see the value of open source software”. His point is that I should give it a rest. He reminds me that Microsoft, IBM and Oracle are the important players. His final point is always this: “I don’t see the value in having open source”.
An article in CIO revealed the twin contradictions of “offshoring” software development:
- code is so unimportant that we farm it out and so critical to success that we can’t stop producing it;
- our people are incapable of producing the code cheaply enough and we have to use the programming languages our people know and they only know ineffective programming languages.
Offshoring appears to be the result of some kind of dogmatic article of faith: COBOL is the only language my people understand. The unstated premise is that we must do COBOL; offshoring is the only way to keep the price down.
There a number of degrees of freedom in the offshoring value proposition. Here’s my suggestion: reject the “must do COBOL” premise. Now what do have?
SD Times has a big piece on C#, “One Language To Bind Them All” [link ]. It hits me in a tender spot.
“You forgot to add “for me” to the end of those sentences. Obviously, you’re entitled to your opinion, but at least make it clear that you’re quoting your view, and not a universal truth.
For me, I find XSLT far more opaque than Perl. I also don’t know Fortran that well, so it’s a bit more opaque than Perl to me.” [link ]
Good point. And, I think we’re agreeing.
“It seems that Perl does not have frameworks ?” That isn’t true, and it wasn’t my point.
Recently I’ve had a number of conversations on what do with aging Perl code. Problem? It’s hard to read, making it hard to maintain, making it an expensive legacy. What to do?
While some spread-sheet use is civilized numerical stuff, and other spread-sheet use is merely personal organization, too much spread-sheet use is the poor-person’s database management system.
Sometimes we can’t articulate all the use cases very clearly (since a spreadsheet doesn’t enforce much discipline) and when in-house IT wants to talk about it, the meetings drag on, the costs rise.
First, MS writes crap software that is the foundation for virus, spyware and malware. THEN, to make it worse, you have to get an add-on product. And when someone says “free beta”, the next step will be “pay to have the holes patched”.
Kontrawize says [link ] that Java is the new assembler. I disagree. It’s the new COBOL. Here’s why.
See [RLucente ] for some comments and feedback.
See SDTimes [link ] for some more thoughts on RentACoder.
Building Skills Content Management Culture of Complexity Databases and Python DocBook Economics of Software Macintosh Methodology for Non-Programmers Open Source Projects Personal Web Toys Technology News Test Driven Reverse Engineering The Lure of XML Unit Testing in Python User Interface War Stories and AdviceThere is a growing marketplace for code and components. Why hire? Why staff? Why not just purchase the code?