"Enterprise will follow legacy to become a common insult among software creators and users"
I don't think legacy is a bad thing (definitely better than failed projects), but I definitely agree with David H.H.'s post that the concept of "Enterprise" software has lost a lot of luster. I have been part of a couple of these roll outs, and it's never pretty. There's something about software that is supposed to everything that makes it do nothing particularly well. This "Coding Horror" post linked to in the comments is even more to the point. Enterprise buyers seem to purchase based on the number of checkmarks in the feature list, rather than based on how well any of those check marked features actually work. Would you buy a new car based purely on the spec sheet?
I can think of one situation where we had a large number of users on a client/server ArcView system that I had put together in 1996-1999. We worked out a nice locking system for multi-user access at different sites and built a lot of custom extensions. There was a massive push in 2001 to replace it with a web based "Enterprise" system based on ArcIMS. I tried to help them out for about six months, but it was obvious that ArcIMS at the time was only going to be able to provide about 50% of the features and performance to which the users had been accustomed. Plus, they now had to ask someone to add new base map data instead of being able to add it themsleves among other indignities. I escaped prior to the first deployment, which was a complete disaster and the project eventually skidded to a halt.
Honestly, there was no need to replace the system, it just needed a new name for political reasons as two projects were being merged. As it stands, they are still cruising along as we head into 2006. The project might actually make a little more sense now that we have some better web browsers available, but there are some tasks that you just don't want to do in a browser. I feel like the enterprise version of Photoshop would be browser based, with some workflow where you had to get managerial approval before you changed your color pallette.
Friday, December 30, 2005
"Enterprise will follow legacy to become a common insult among software creators and users"
In an article that is creating a fair amount of discussion, Joel (on Software) Spolsky rants against kids learning Java in school. I think it's a bit of a strawman, as I don't know of any schools that only teach Java to CS majors, but that would be pretty sad. I think in four years you ought to have time to really learn a couple of languages, and get exposed to a few more. I wish I had been able to take MIT's 6.001 [see image for objectives].
I like the approach of starting on both sides, with a high level and a low level language. If you can see how assembler works, you can start to see the reasoning behind things in c works, and then when you see a bunch of c code, you understand why a lot of the memory management and abstractions were added to the other languages. I like the idea of understanding what things are more efficiently accomplished in a high level language versus which things need to be done in a low level language in a hands on fashion.
Now, what about the people that can only deal with the abstractions? I mean for reasons of patience or just lack of interest, some people aren't interested in understading things all the way down. I don't think it's wrong to stop at a particular level of abstraction for those people. Maybe they don't need to know about pointers, but it is going to limit what kind of work they can do effectively.
Maybe the right answer is that you have to understand at least one level of abstraction below where you work. I think that is enough to uncover one level of problem. I have run into Java programmers that know a little c++, but didn't realize all of their variables were pointers to memory, and they do have problems writing code that takes advantage of that fact. The pointers are still in there in the languages that abstract them away- it's just a little harder to screw them up, or make them do exactly what you want.
Posted by Matt McKnight at 9:38 AM
Thursday, December 22, 2005
To me this is the essence of what is wrong with letting the Enterprise Architects dictate user experience. James McGovern, an enterprise architect whose book I really like, has been going on and on about how "web 2.0" is not something that architects should be thinking about. [see his 2006 predictions post for an example] I really think it is something that they should be focusing on- improving the user experience. I think if you think that way, you build an Excel import function. If you think the bad way, you build a complex user application that is buzzword compliant ESB, SOA, EBI, etc. forgetting that the spreadsheet is the application whose usability and flexibility drove the adoption of the PC (and that your corporate developers probably aren't as good as the people at Microsoft that wrote Excel).
Wednesday, December 21, 2005
Over on All Points Blog, they consider why a NY Times article on Google Earth was the most emailed on the site for a couple of days,
I think the reason is very simple- people have been unaware of the existence of high quality commercial satellite imagery and aerial photography. The only thing Google can be accused of is lowering the price, making it easier to use, and publicizing it to the point where uninformed people in positions of power can begin to make themselves look foolish in the press. The headline on the article, "Governments Tremble at Google's Bird's-Eye View" is an alarmist overstatement (given that there was no evidence of trembling presented) that colors the perception of the reader, making something out of very little.
It reminds me of the situations that occured when various governmental organizations began putting public records online. A lot of people were uncomfortable with what was considered public record (how much they paid for their house, how much money they gave to political candidates, etc.) and the fact that you could click to it from the comfort of your home instead of waiting in line at some county office somehow made it newsworthy.
Posted by Matt McKnight at 11:11 AM
Tuesday, December 20, 2005
Google has provided a little interface- compare to JSR-168, for adding sections to their homepage. I read the document and added a little one to run the mobile version of Backpack in about 3 minutes. Obviously, there's a lot more you can do with this- particularly the location aspect.
<?xml version="1.0" encoding="UTF-8"?>
<ModulePrefs title="Backpack" />
<Content type="url" href="http://username.backpackit.com/mob"></Content>
Posted by Matt McKnight at 9:49 AM
Monday, December 19, 2005
Drop the: "Back when we cooked up XML in 1996-97, there were good reasons to have that ugly upper-case gibberish at the top of your XML documents. That was almost ten years ago; now it’s time to do away with it, and also time to have a spec for Doctype-free XML."
Tim Bray is ready to drop the doctype. I am too. I am not overly fond of discussing the foibles of my colleagues, present or former, preferring to discuss topics in the abstract. However, a particularly heinous form of idiocy that I was exposed to in a previous consulting engagement was related to this. These folks were operating on a network that was not connected to the internet. They were concerned that all of these doctype declarations in XML were referring to things like http://www.w3.org/TR/html4/strict.dtd. So, they wanted to do the logical thing and create websites on their internal network that resolved to those addresses and host the DTDs there. You know, so they could download the DTDs and parse the files. I think a similar group at that organization expressed a great interest in starting a project to provide a buzzword-compliant web service to actually perform validations of XML against Schemas and DTDs. Which would of course have been accompanied by an enterprise policy that forbade anyone else from validating XML....
I really think anyone writing a parsing application needs to make sure that they don't put in any dependencies on actually reading the DTD. I always try to parse XML using XPath in a relatively fault tolerant way. I honestly think that one of the reasons for the ascendancy of Internet Explorer was that they went out of their way to try to display as much as they could of any old hacked up HTML that is out there. This to me is the best part of Tim's post->
"...it’s usually a bad idea for a document to express an opinion as to what its own schema is. Most useful languages have more than one schema, and it’s the absolute right of someone receiving a document to decide whether it meets their definition of “valid” before they use it, so they’re going to make their own decisions as to which schema (if any) is appropriate."
I reserve that right.
Posted by Matt McKnight at 9:38 AM
Sunday, December 18, 2005
Even though I should probably be coding, or doing the books, or something else useful, Andrew Glover's basically hype-free Ruby off the Rails (an good intro for Java developers) is up on IBM's developerWorks.
There's also a new Manning book, Ruby for Rails coming out in April that focuses on learning Ruby as you build with Rails.
Finally, this isn't anything new, but the Ruby Scripts for SketchUp page is full of cool stuff, but I am still waiting for them to release some things related to their Google Earth integration. You can find some references in their forums. If you have seen those really cool 3D models of buildings that people have been throwing together, you may not realize that building models is pretty easy compared to other 3D tools.
I think if the decision had been made this year, ESRI might have chosen Ruby over Python for ArcGIS scripting. As it is, I am glad they have kept a simple language in there, even if it isn't Avenue...
Posted by Matt McKnight at 10:58 PM
Tuesday, December 13, 2005
Rails 1.0: Party like it's one oh oh!: "15 months after the first public release, Rails has arrived at the big 1.0."
Getting to a 1.0 release is really going to make this easier to use in a variety of contexts. Ruby and Rails have really brought a sea change in my way of thinking about the best way to develop software. I am not 100% happy with it, as it seems to be a little too "database driven", but there are a lot tricks in there to make it less so. I think that is one thing that really separates it from things like Oracle's HTML DB. HTML DB is great for generating database driven web applications, until you want to do something outside of the framework, then you are alone in a cold dark place with nothing but burning pl/sql code to keep you warm.
There's something nice about having code generation vs. a pure wizardry approach that leaves you nothing to modify. The downside is, of course, that your changes are overwritten if you re-gen. A beauty of Rails is that if you add a field to the database, it is accessible in the model, but it still must be added to the user interface. One mode of development is to start by modifying the templates for code generation such that one can always add fields and regenerate the UIs, at least. I haven't gotten that deep into Rails yet, but that's the direction I am going.
One of the things about Rails that really surprised me was that the scaffolding generates a web service to go along with the web pages for a particular domain object. I think this is a really interesting feature that will also probably be assimilated by database companies, if it already hasn't been.
Posted by Matt McKnight at 11:10 PM
Saturday, December 10, 2005
How XML Killed Java (A Contrarian Perspective): "In the early 21st century, computer programmers often used statically typed languages, especially Java. While these languages were suitable for small-scale projects, they were not as well suited for enterprise class systems, where flexibility and adaptability were (and are) primary concerns."
The basic premise is that by using XML for integration Java has opened itself up to any other language being able to read that XML. And by using XML for configuration, Java has become dependent on reflection, which removes many of the benefits of statically typed languages.
As someone who has to plead guilty to creating flexible systems by using external configuration files- there is a limit to that approach. I actually prefer to keep the configuration in the database, as opposed to XML, but the net effect is the same. If you are making your system truly configurable, using a dynamically typed language is one of the easiest ways to enable that.
Posted by Matt McKnight at 11:27 AM
Yahoo! Buys del.icio.us, it will be interesting to see how quickly it gets connected to the other Yahoo properties.
In particular, I think there is a way del.icio.us is used to store placemark equivalents. I like the ability in local.live.com to just right click on the map and have that create a point. Using del.icio.us to manage those with Yahoo Maps would be cool...
I think del.icio.us could really lose value if they don't remain an open application thing. I think Yahoo! basically did the right thing with Flickr, even if there was some whining about the change to using the Yahoo ID system, there's a lot to be said about common identity as the basis for integration. I also like how Yahoo opened up the Maps geocoding API, which could not have been cheap to do, but is the right thing to do.
I expect to see the same integration and consolidation thing happening for del.icio.us, which potentially makes it a lot more useful, or could mean people just stop using it. There is some value to del.icio.us independence that is being lost, but hopefully the integration gains are greater. I think of it as a corporate mash-up: Yahoo buys del.icio.us so that they can do official mash-ups with all of their assets. You just have to hope they don't do anything to disable all of the unofficial things that already exist.
Posted by Matt McKnight at 8:36 AM
Friday, December 09, 2005
A cure for the common inbox: Posted by Jared Jacobs, Gmail Engineer
Right place- wrong thing. It be much niftier to integrate Google Reader. I see this as something that is more for people who still don't really get the whole subscription concept. I am not one of these people who wants rss feeds in my inbox (unless they are the search alerts associated with ME personally), but I would like to see a little integration.
Google could now have four separate lists of RSS feeds for me associated with the personalized homepage, the afforemention Reader, Google Desktop 2, and now in Gmail. Only one of these imports OPML...if I worked at Google my 20% time would be spent 100% on at least loosely integrating all of the stuff they already have.
Posted by Matt McKnight at 11:43 AM
Thursday, December 08, 2005
So, I was reading the new Squidoo lens on the Long Tail, and I realized it's becoming one of those things that can mean whatever you want. Something bothered me when I saw this thing a couple of months ago from Dave Bouwman.
The first thing is that the long tail isn't that long, relative to the short tail. Or, rather, the area under the tail is pretty small. I wonder what would happen if we had actual numbers on the y-axis: does anyone know how many users there are of Mapquest, Yahoo Maps, Google Maps, Windows Local Live/Virtual Earth, Google Earth etc. compared to the users of specialized GIS tools? It's probably a pretty high ratio. This makes the long tail a lot shorter, and the slope a lot steeper.
One reason that the Long Tail makes a lot sense for things like books is that there are millions of books to choose from. But it's not the guy that sells one book out at the far end of the tail that gets rich, it's Amazon with a virtual warehouse that sells the whole long tail. If users paid for their GIS software per use, the model might make some kind of economic sense. The people that use GIS alot, want some complex GIS features. The people that are looking at pretty pictures and want to find the shortest route to Grandma's house (it's over the river and through the 'hoods) don't need it, in fact, they don't need to pay at all.
The real question is at what level people will start paying for features. There is a point somewhere between Google Earth Pro and ArcInfo where people really do have a choice in terms of what to buy. The biggest change that has developed in the past two years is that the feature list of the free stuff keeps creeping upwards, and taking some of the left side of the tail away from the people that sell things. When you have services with APIs and lots of free data, that changes the game. It grows the whole market, so there is a lot more demand for data, data that has to be created with the advanced tools.
Anyway, I'll draw up a new tail tomorrow and we'll see how it looks.
Posted by Matt McKnight at 10:13 PM
EVM is a messed up concept. I estimate the design will take 20 weeks. It takes 10 weeks. I earned 20 weeks of value, yea!!! Except there's no value to the customer. Don't give intrinsic value to time- give value to the actual value delivered to the customer.
Of course, working for the government, they can demand that you give value to the non-real tasks. I tried to read the document from the CIO Council, searching for any guidance that the tasks to which value is assigned are tasks that have direct value to the customer, not tasks like "create test plan".
In IT projects, value only comes from value delivered to customers. Putting meetings on the schedule and "earning value" by getting to the end just doesn't make sense.
Posted by Matt McKnight at 9:36 PM
This is a funny little post about "the fall from scaffolding". I had never really imagined that people would try to completely depend on the scaffolding and not actually stick any of the back end code in there, but I guess it's more than possible, it's happening.
I think the comment by the Python guy on Django is a little sad..."Rails just gives you scaffolding, Django gives you the whole house!
" He's taking the angle that the author is just now discovering that there's more to Rails (and Ruby) and using that to imply that there is nothing else there, and some how more in Django. Sick rhetoric- why does everything have to be such a competition. I think people should have known for a long time that it's not comparing feature lists that makes people choose one technology over another. If it was, you'd pick out your car strictly from the spec sheet without looking at it or taking a test drive.
The test drive that comes with Rails is really really good. The acceleration (in terms of how long it takes to get running) and miles per gallon (in terms of features delivered per hour) are great too, but it's really about the feeling you get that makes it different.
Posted by Matt McKnight at 5:59 PM
Remember Virtual Earth? Forget Virtual Earth....
In a move that seems really really too similar to the Google Maps to Google Local transition, we now have Windows Live Local.
I think it is much clearer that this is a competitor with Google Local than Google Earth, even with the 45 degree angle shots that I clipped here. I also think it's interesting that they are calling this Windows Live versus Microsoft Live. I think Windows is a far better brand than Microsoft. The Microsoft name just has far too much baggage associated with it in too many contexts, whereas Windows and Office are really seen in a much more positive light. I'd be interested to see some numbers behind that.
Posted by Matt McKnight at 10:43 AM
Refactoring and Code Completion- two things about Eclipse that are very hard to give up when typing in Ruby. Jon Tirsen's post sums up the challenges in Ruby pretty well, although there are some innovative approaches for doing things like a rename, if you have a fully automated test suite that will throw deprecation warnings.
It's not like Java or (C#) is completely immune to these kinds of things. Once you start writing framework style code (like an O/R mapper or something with great gobs of XML splattered about) and using reflection and the Class class all of the time, a lot of the type safety disappears. In most cases, a class cast exception is no better than what would happen in Ruby. The concept of method_missing is also a neat way to deal with what happens when duck typing fails.
In any case, the ascent of dynamically type languages continues. Python, which appeared to be the heir to Perl, is rolling with some well made new web frameworks. Ruby is selling more books though, according to Tim O'Reilly. The debate Ruby vs. Python really doesn't matter toooo much, although I suspect that the Ruby will end up in more enterprise locations, once people like Justin and Stu get the Enterprise kinks worked out.
Anyway, I know code completion and refactoring make me a lot more productive. It is an open question whether the other gains of Ruby/Rails make up for that loss.
Posted by Matt McKnight at 12:32 AM
Monday, December 05, 2005
I am seeking resumes from geniuses who want to do consulting on enterprise installations of Google Earth in the Washington, DC and Baltimore, MD metro areas. US citizenship required. Resumes and cover letters to email@example.com
Posted by Matt McKnight at 10:15 AM
Sunday, December 04, 2005
Well, there aren't many discussions yet, but SlashGISRS is using the same website engine. Where is the best discussion forum for GIS in the general perspective? I tend to spend time on the ESRI Developer Network (despite it's limited Java and Avenue coverage) or the Google Earth "BBS", but neither of those is really a general purpose site.
What makes Slashdot Slashdot is the community. There's enough people posting stories and commenting on them that it actually ends up getting interesting information fast. So, while using the same software is great, SlashGISRS (why the rs?) needs commenters and submitters to be worth going to. Aggregation without editors is the other approach, and there may be some smarts that can be put in there to keep the most interesting and recent stories up there, but that's not as easy as it sounds.
Posted by Matt McKnight at 10:41 PM
Friday, December 02, 2005
To be able to take ArcGIS Server, ArcIMS, WMS, ArcWeb Services and other types of GIS datasets and display them all in one program really speaks volumes of what ESRI is trying to accomplish here. ArcGIS Explorer seems to be the product that Google Earth should have been.
It seems really snide to say "should have been". Google Earth isn't just a client- they're serving up an unprecedent quantity of imagery, elevation, and vector data at amazing speeds to a huge number of users. That really changed the game for all of the people that don't have ArcGIS Server, ArcIMS, WMS, etc services that cover whole world available to them. GIS isn't much fun without good data, and Google Earth has exposed a lot of people to data that they didn't even know existed.
By James's definition of "should have been", Google Earth should have been the viewer for ESRI data formats...maybe if Keyhole had been looking to get bought by someone else. In reality, the server side of Google Earth changed the game in terms of scaling 3D imagery services and the client changed the way most people who used it thought about GIS user interfaces (apparently to include ESRI). Hacking across data formats is a nice side business for system integrators, not really the primary focus for most innovative product companies [reference ESRI support for OGC standards].
Here's one big thing missing from ArcGIS Explorer so far- the ability to create data. A community sprung up around Keyhole and then Google Earth in large part due to the ease of creating data and sharing with it others. Now, you probably wouldn't use this kind of tool to produce datasets that you would sell, but it handles the long tail of applications for the occaisonal GIS user.
Posted by Matt McKnight at 1:32 AM
Wednesday, November 30, 2005
with everything but Java itself?
I don't know if this is the greatest idea, but their products weren't doing well before they went open- how will then do now? I think the adoption rate won't change drastically. I guess a second question is how will it affect the future quality of these projects. Just because they are free and the source is open, there isn't a community of developers around these things that Sun will be able to leverage (such as the amazing community around Eclipse). So, what do they gain, besides maybe making BEA and IBM drop their prices? My guess is that they won't drop their prices- and now they have some numbers to say that Sun doesn't think there software has instrinsic value, while theirs is worth upwards of $10k/CPU.
Posted by Matt McKnight at 2:43 PM
Monday, November 28, 2005
Thanks to one of his comments, I read through all of Geo-Web.This blog does a decent job of expaining what the heck GML is. GML itself is one of those things that is too "meta" to be of use to most people, but GML application schemas and profiles defined for particular purposes can be useful. The author tries a lot of analogies to explain what GML is, but it's pretty different from most things.
Think about the specification for SQL- most of us never look at. In fact, we are usually only concerned with the variant of SQL that applies to the database we are using. We might try to write database independent code, but what's a VARCHAR here is a VARCHAR2 there etc. We then define different databases using the DDL (Data Definition Language) aspects of SQL, and you end up with particular columns and tables, etc.
Now, imagine if the specification for SQL was written in XSD. That's the thing about GML that could make your head fall off, it's like a specification for creating XSD, written as an XSD. And by the way, the schema for XSD is also an XSD. This is what makes us not love the XML folks so much.
Ben Galbraith has a great story and presentation on this stuff, here's a recent article on this stuff.
Posted by Matt McKnight at 4:08 PM
I think a great definition for beta is things that are feature complete, but not yet fully tested. If you want to do a release that is not feature complete- whatever your definition of complete is- I would go with a 0.x numbering scheme. The guy in this WSJ article who says his site is beta because he hasn't finished all of the features yet, seems to be a little misguided. It would seem that beta has come to mean "not finished", as opposed to "not fully tested".
I blame Google for this, although everyone else is getting in on the game as well. If you call your first live public site a "beta", it doesn't leave you a lot of room for improvement. I think the expectation this it lets you get away with buggy software, which is entirely different from incomplete software, is a bad expectation to create. In fact, one could argue that few software products are really complete (even after they begin sending email). From agile perspective, we should be getting more comfortable with releasing evolutionary products, but they should products where a limited set of features work correctly, and the ones that don't are not included.
Posted by Matt McKnight at 2:57 PM
Previewseek web search: "
Beta web search Previewseek aims squarely at Google and bills itself 'the world's most advanced search engine.' PreviewSeek's about page compares a search for the word 'Java' on Google and says its results are smarter:
Previewseek immediately understands that the word Java can mean many different things. Did you mean Java the island, Java the coffee, Java the programming language, or Javanese (the language spoken by people on Java island)? If you are not sure, Previewseek immediately gives you definitions of each different meaning. On Google, if you were interested in Java the island, you would have to click through over 70 pages of irrelevant results for 'java' before getting to your very first relevant result! In Previewseek, you just need to click once to get all the appropriate results.
Uhhh...maybe you should just query "java island". It really annoys me when people do some dumb query on a single ambiguous word and complain about the results. The previously mentioned search even gives you some options for "java island map" as a suggested alternate query.
Posted by Matt McKnight at 2:27 PM
WebWork merging with Struts to become Struts Ti: "Patrick Lightbody, in 'WebWork joining Struts,' has announced that WebWork is going to merge into Struts, becoming the 'Struts Action Framework 2.0.' The main benefit for WebWork, he says, is the Struts community, while Ted Husted says that the intention for Struts Ti was to use WebWork as the core for the action framework."
This is an interesting combination- I wonder which parts of Struts they would keep in this scenario? Two places where it was always lacking were in the construction of multi-page flows and in simple UI construction. I think the problem with a lot of these frameworks is that they just go too far down the old configuration road. If everything is configurable, you don't really have an application, you just have another layer in a stack. Too many of these things make you feel like you are programming in XML, rather than using it as a data representation format. Maybe they can slide in some Rails style convention over configuration principles in as part of the integration....
Posted by Matt McKnight at 12:22 PM
Sunday, November 27, 2005
Thought Experiments>Tim Bray has some interesting thoughts on the new Office XML formats. One of the key elements here is backwards compatibility. Microsoft over the years has gone to amazing lengths to preserve backwards compatibility in its products, at the cost of simplicity. It still seems to be a weak argument in this case for including that in the new XML format- even though there are billions of legacy word documents, that doesn't mean they should be in the new format. It's far easier to build support for the old formats into the new Office suite and support for the new formats as a plugin to the old Office suite.
Still, the question of whether Microsoft or OASIS have come up with the better format is a fair one. However, that should be evaluated on the basis of features and performance, not by who came up with it. The idea Tim has of getting them to agree on the basics is good one. It reminds me of how KML uses the basic GML standard for points, while putting it's own structure around it.
XML does allow for sharing the common bits with namespaces. Maybe the world should switch to RelaxNG... another great OASIS standard. Then we might be able to know what we are doing. With XML Schema, all too often, the meaning is obfuscated by the syntax.
Posted by Matt McKnight at 10:18 PM
Friday, November 25, 2005
Google Analytics- amazing how something this cool got so much bad press. It seems to be a natural human tendency to try and cut down those who are doing well. Anwyay, this picture [click for the larger size] shows where you all (the measured readers of this blog in non-rss form) are located (with the exception of India, who was cut for purposes of scale). Very interesting, I think it's hackable into a Google Local map.
Posted by Matt McKnight at 10:35 PM
Just wrapped up reading this one on my flight from IAD to SFO: Agile Estimating and Planning, by Mike Cohn. It has some very practical direction on how to put agile planning practices in place. I think a lot of people need materials that are pretty detailed. I agree with the principle that methodologies should be adapted to fit the needs of the teams, but having all of the options laid out makes that a multiple choice decision, rather than a free response.
I faced the very trials that he described when attempting to figure out how to put story points or ideal days in place for size estimates. Ideal days do make that initial hump of estimating easier- they give people a frame of reference. Once we did that a couple of times though, I just switched to a couple of size measures (Extra Small (0), Small (1), Medium (3), Large (5), Extra Large (10)) and everything bigger than 10 ideal days had to be split into smaller tasks. At that point, the numbers were just relative sizes, and we could call them points without anyone thinking we weren't being serious.
The one place that I thought the book fell down was the one thing I was really looking for advice on, how to transition from that list of things that you are about to tackle in an iteration to the particular assignments that have to get handed to developers. Mike recommended doing some detailed estimates at that point, down to the hour level. I have to say I am closer David Anderson's approach on that point. Don't estimate at that level. However, I think David's all or nothing approach of doing no estimating is really only appropriate for Feature Driven Development, where all of the features are roughly equal. With the approach we usually take, bug fixes and everything else have to get factored in there, and there can easily be order of magnitude differences between the amount of work for each work item/task. However, coming up with the size estimates is pretty easy when there are only 5 choices.
So, Mike's book is good- far more practical than most of the other agile management books that seem to be coming out of the woodwork... You should check it out. The price jumped up pretty high on Amazon, but it's worth it.
Posted by Matt McKnight at 9:59 PM
Wednesday, November 23, 2005
This one makes even less sense than proprietary APIs- there is criticism of KML claiming that it is a proprietary format. I suppose the comparison is to GML, which is supposedly a non-proprietary format. In what sense is KML proprietary?
- It's an open format. Published on the web. Documented.
- There is no use restriction on the format. Other vendors and developers are encouraged to use it.
- It is widely used and implemented by a growing variety of vendors.
- Suggestions and comments on the format are accepted via a public forum.
- Even the compressed binary format (KMZ) is just using the common zipfile compression algorithm, which has implementations on every operating system and modern programming language, rather than something that you need to buy a seperate product to use.
It would appear that the only salient difference in proprietary-ness is that KML was developed by a single company (albeit with input from others), whereas GML was developed by a standards committee. The salient difference in the marketplace is that KML is usable and hand-editable, whereas GML is rather too complex for use without tools. In contrast to what one might expect, the standards committe developed format requires tools to create, whereas the one developed by Keyhole does not. Then again, looking at the history of the OGC, they were primarily pushed forward by the other vendors attempting to cooperate in opposition to dominance in the marketplace by ESRI and ESRI formats such as the shapefile and the arc .e00 formats, which had become the accepted interchange formats for vector data. This infighting has led to OGC standards in most cases being worse than standards which have been defined by individual vendors.
So far they have only been able to come up with "superset" type standards which have been overly philosophical in their approach- not designed with implementation efficiency in mind. I think there is a something to be said for formats that have been proven with a high performing implementation. Think of a reference implementation, such as Apache Tomcat now is for the Java Enterprise Edition for the Servlet specification. It is possible to create a poorly defined or bloated spec such that the implementations are going to be burdened by poor performance.
The proprietary label should be reserved for those formats which are protected by copyright or obfuscation and don't allow for open use- think of the various DRM music formats offered by Apple and Sony- not an XML format that is documented on the web. And oh yeah- ESRI is supporting KML now too- if you need any more proof that it's not proprietary, you must work on a standards committee. I've been there, I'm not going back.
Posted by Matt McKnight at 10:23 AM
Tuesday, November 22, 2005
I have always been a prety big fan of Ray Ozzie of Lotus Notes and Groove fame. I think he has really nailed all of the complexities of synchronization and replication in his products. If you compare how long it takes to set up replication for a Notes database to how long it takes for an Oracle database, you will see what I mean.
Another technology that I have been a big fan of since discovering it is RSS. RSS is dead simple- an XML format for html links and their summaries. It is a bit of a mistake to call it "a format", since there are several popular versions of RSS and Atom out there. The whole concept of having an RSS feed for a site, search, or topic that you are interested in is that you can have a tool watch that file for changes, and then display the summaries of the new content to you, allowing you to decide if you want to click on the link to the original source.
Now, Mr. Ozzie likes the dead simplicity of RSS, and thinks he can do the whole magical synchronization/replication thing one more time, but this time with a creative commons licensed standard that will do it for the whole web. His first little example is a calendar. I love it because my whole team has this problem while working at customer sites without their mobile devices. I also love it because it almost seems like he developed this whole technology to solve a problem that he and his wife were having with synchronizing their calendars. In two weeks. And if it's going to be in Office/Outlook/Exchange, it's going to be a viable solution for the whole internet. This may mean no built-in iCal for Outlook, but maybe we don't need that anymore.
Posted by Matt McKnight at 9:37 AM
Although they are on Debian, these instructions seem pretty detailed.
I am looking to do this soon with my little HR system. I also have a strange desire to write an agile planning tool, but do it mostly as an integration project. I am interested to see how Rails does as glue code versus how it does building apps. I have a feeling it will do well.
Posted by Matt McKnight at 9:29 AM
Monday, November 21, 2005
Kent Beck describes developer testing as one of the XP practices that can done on your own. In other words, you can do it without any buy-in from the rest of the team. You can load up JUnit for free and then start testing.
If your code is noticably better, if other people have the tests as a guide to how to change your code, people might get interested. If there are skeptics, you have to wait for that “teachable moment”- when they have a tricky bug that you can help them fix by writing a test, running the test, making a little change, running the test, repeating until it passes. Little by little, opinion can change that way. Just repeating “we need to do developer testing” doesn't have the same effect.
Working on your own does have disadvantages. Finding a community of people that can help you make the change. Even if you're the only one doing developer testing on your project, reach out across your company, reach out for like-minded individuals.
Posted by Matt McKnight at 10:42 PM
In this discussion over at TSS, the concept of proprietary APIs came up, with Hani Suleiman labeling Hibernate and TopLink proprietary, and EJB 3.0 as non-proprietary. I have seen this logic again and again, and it is wrong.
Nothing makes the API of Hibernate more proprietary than EJB 3.0. You could argue that one API is defined by the implementors and the other API is defined by vendor approved expert groups, but which is which? The difference is that there is only one proprietary implementation of the Hibernate API at the moment, and there will probably be multiple proprietary implementations of the EJB 3.0 API. The very nature of published APIs is that they cannot be proprietary, only the implementations can be. While there can be copyright or other restrictions on them, those generally are not published. See .Net versus the Mono project. There is nothing but time to stop BEA from putting out their own Hibernate 3 compatible code that is optimized for their app server, it might even be worth it for them to do so.
Another important thing to think about is which APIs are better- those designed by committees to address the needs of everyone, or those that solve specific problems? If we were talking about applications, I would choose the latter. I might do the same for APIs.
Posted by Matt McKnight at 11:28 AM
Friday, November 18, 2005
While I am not sure they have finished scaling the response processing, the user application for Analytics is now quite responsive, and is just really a cool web app. Here's my question- why no GoogleMaps integration?!? Every twobit js hacker with a dot to plot is doing gMaps integration, and these guys have a doinky flash map that zooms in on everything (not just the map, the label text gets massive too).
Still, better than I had last week, which was nothing. I wonder about this whole "free stuff" strategy though. It seems like Microsoft used to do the same thing, and ended up getting a really bad name for putting little companies out of business. I guess we can be glad that Google at least buys one of the little companies before it makes the products free, but the competitors are going to be hurting. The other problem with free is that implies that the product has no value, or is annoying (adware). Somehow Google have made adware palatable by limiting it's reach. Reminds me of the anchor reading the sponsors' messages on NPR compared to the other stations where the commercials blare at 150% of the normal volume with some jerk shouting.
Posted by Matt McKnight at 11:16 AM
Tuesday, November 15, 2005
Pissed at Google: "We seem to be hearing from more people that Google doesn't do that great a job outside of its core focus, search. So again, when Google decided to make its Web analytics software free yesterday, some people weren't happy with how the company handled it. They were pissed, says Ethan Stock, chief executive of valley events start-up Zvents. "
Well, they should have done the gmail thing and scaled this thing gradually. This was just too good. The Zvents guys doesn't get it either, they did cut off signups pretty quickly. But it looks like it was already too late for them to serve up their current customers.
I think one idea for scaling things up would have been to keep current customers on the existing infrastructure. I have to assume they had no idea how many people were looking for a cheap and easy web analytics solution.
Posted by Matt McKnight at 4:58 PM
Monday, November 14, 2005
Posted by Matt McKnight at 3:20 PM
Tuesday, November 08, 2005
How To Use CIA For Continuous Integration: "CIA runs on the server where your Subversion repository lives. It watches for commits, checks out the most recent tree of the related project, and runs all the unit & functional tests. If there are failures, they are logged to the database, as well as emailed to a pre-configured address."
It seems like many of the CI tools have interesting names- Cruise Control, Damage Control, now CIA. Beyond the names though, anyone doing team development needs to be doing this.
Posted by Matt McKnight at 3:53 PM
The Day When Microsoft Pays You To Use Their Software: "An opinion piece over at Silicon.com is joking about how Bill Gates should be paying people to use Windows in response to a Bill Gates comment that Google should be paying people to use its search engine....Meanwhile, with Microsoft's recent announcement that they're focusing on software as a service, they did clearly say that they expect much of it to be ad supported. While many people question whether or not they can actually pull that off, if they can, how hard is it to leap from ad-supported software to 'make money' supported software?"
If everything is ad supported, who's going to buy the ads? It sounds like a bubble to me.
Posted by Matt McKnight at 3:49 PM
Friday, November 04, 2005
Ruby is nice, it's a very concise Object Oriented language with a good community around it. But there is some weirdness. One selling point of Ruby is that it is dynamically typed- you don't have to declare variable types, which allows for a lot of flexibility. However, there is a cost in that those of us lazy types that have been saving the part of our brain that remembers and types out method names on objects for more important things. Well, I'm actually just letting that part of my brain rest. Now, with Ruby, I can't hit the [.] key and get a list of all of the legal calls, because, I could literally type anything and it would work. There is a magic thing called method_missing that lets you call things that don't exist.
Anyway, I think I should at least be able to get the list methods that are available in the object and its super classes, if the IDE knows what class we are dealing with, which is possible when you have the types declared. I am downloading Komodo now to see if that pans out, results here tomorrow?
Posted by Matt McKnight at 12:49 AM
Thursday, November 03, 2005
Posted by Matt McKnight at 3:27 PM
The new Yahoo!Maps beta looks like a decent ripoff of Google Maps GUI. They added a very cool overview window that previews your zoom extent. They even updated the Ajax API. Very nice. I was a little disheartened to see all of the Flash APIs. I really hope web development doesn't go in that direction, as I don't really like the interaction between those components and the rest of the page. However the JS-Flash API appears to make everything accessible with no Flash programming required, so maybe that is least evil way forward.
Posted by Matt McKnight at 2:52 PM
Tuesday, November 01, 2005
I used to work for a government customer that had (has?) a hideously bloated and rigid process for building software systems, that completely forgets about the actual building of it. I recognize and appreciate the parts of that process that have to do with project selection and budgeting and the like. However, it has completely glossed over the building of the actual software. In a 3 year schedule template, only 30 days are devoted to actual development. It's inside out. It also doesn't work.
Anyway, I was in there before trying to sell agile processes- and basically failing. It was hard enough to get them to buy into iterations, becuase their whole mindset was based on control gates as the measure of progress. Of course, the only control gate with any teeth was "user acceptance review", so you had to wait until the bitter end of the project to find out how far things were off course.
Now I am realizing that the agile process I was trying to introduce need to be sold as MORE process, not less, as I had presumed. We are really addressing massive gaps in their structure. The problem becomes layering this inside of a existing framework of control gates. So, if we have a systems requirements review, the waterfall methodology suggests that we cannot pass this control gate until we have all of the requirements gathered in specific enough detail to begin design. Of course, this is an out of control gate you just sail through, unless your reqs happen to tramp in someone else's turf, in which case you have to fight to have a widget in your app, because some other project is in charge of those types of widgets.
The real mindset change is, after a certain point, replace control gates with measures of actual progress, such as running features. But how do we know if the requirements are right if we don't have a requirements review control gate? Well, first, the control gate never did work, so maybe the requirements review=the acceptance test. The only control gate with real teeth is the one we should use. How do we validate the design? Performance test it. By bringing these tests earlier in the cycle, I feel like there is a way to actually evolve the current process, rather than to blow it up.
Agile is scary for lots of reasons, but I think they are good reasons. It's kind of scary to say that you have to have working code early enough to do an acceptance test on it at the beginning, but that's exactly the kind of scare that is need to ensure quality gets built in from the start. It's kind of scary to give up control gates, but what about replacing these control gates with ones that actually have teeth? It means you might fail earlier, rather than being able to coast along for a long time without having to show results.
Posted by Matt McKnight at 12:38 PM
Sunday, October 30, 2005
Wednesday, October 26, 2005
"Who Owns XML"
This is a ridiculous article and a ridiculous patent. The patent has no more to do with XML namespaces than it does to spreadsheets or SQL. Scientigo are nothing more than thieves. Rather than get the company spin, why wouldn't a "Tech Review" evaluate the contents of the patent, which seem to refer to ideas of what inventions could be created, rather than containing the specifications for actual inventions.
Posted by Matt McKnight at 5:00 PM
Monday, October 24, 2005
Techdirt comment "While folks are fretting about the impact of video games on aggressive thoughts and behaviors, Clive Thompson is taking an interesting look at how many gamers suddenly get sick of a game they've obsessed over for weeks. His theory is that once you've uncovered all the 'layers' of how a game works, it loses much of its excitement. "
Continuing a loose thread on boredom- which I think is a rather large issue with people- I think this is the case with a lot of things. I quickly become obsessed with finding out how all of the layers of a thing work, and then find that I just lose interest. What does this say about the jobs we create for people? They are not necessarily puzzles, we aren't there to create puzzles, but we should refrain from giving people jobs that they can easily master. I think there is a positive side effect of continuous improvement efforts in that they can lead us to always push forward, and pushing forward keeps things interesting.
Posted by Matt McKnight at 1:50 PM
Thursday, October 20, 2005
I love this slate article on why South Korea is so good at cloning. I would like to create an analagous environment in the company that we are creating. Well, at least the "scientist as hero" part, not so much the "being attacked by China and Japan and having a crazy cousin at my northern border" part. I have been searching for how the dna of the company can be forced to take a certain shape, how to incentivize the right kind of behavior, and how to cook things so that the right chemistry emerges. How big can you get and still remain agile? What do you need to be the driving intellectual force that keeps things focused on the right goal, focused enough to get through the really really boring parts that are necessary to make great software, necessary to ensure that the fun creative parts are utilized in the right way. I don't think you can cook it too much, a lot it just happens by getting smart, open minded people into the groove together and seeing what comes out. Let me know if you are reading this and want to join up.
Posted by Matt McKnight at 2:37 PM
Tuesday, October 18, 2005
Federal Court Shuts Down Pay As You Go Wireless
"BCGI has been found guilty of infringing on pay-as-you-go wireless patents owned by Freedom Wireless. This heralds a farewell to Cingular's Go Phone and Sprint-Nextel's Boost services, both powered by BCGI.'"
I think it is insane that the patent office is letting people patent business models over technology. Stupid patent approvals are a major factor damaging US innovation. Good patents protect technical innovation, they aren't there to create monopolies around a function.
Posted by Matt McKnight at 11:15 PM
Intel's Robson tech speeds laptop startup and saves juice: "
Intel is showing off some prototype Centrino systems that rock the instant startup due to integrated NAND flash memory chips. Intel’s system puts common files like system data and applications onto the flash memory, speeding up their access and reducing battery consumption...we’ve been waiting around for insta-boot for like 5 million billion years.
I have been waiting for this for sooooo long. Why limit it to laptops? The base files for Windows should have been on memory chips for ages. Flash memory is sort of the perfect solution. ROM is too difficult to update, but flash is pretty quick (faster than disk) and updatable. And lots of computers are coming with flash card slots. My printer/fax even has one. Maybe I could boot windows off of my printer....
Posted by Matt McKnight at 9:49 AM
Sunday, October 16, 2005
The NY Times article on productivity [reg required] is getting a lot of attention. I have suffered from what I feel is rapidly diminishing productivity in recent years, some of which I believe is due to constantly divided attention. I was turned onto getting things done simply because I felt like I wasn't.
I think it comes down to people continually, progressively becoming more easily bored. In lives with constant stimulation, applying the focus required to get something done, something less stimulating than trying three things at once, seems boring. I think of the tv screens with multiple tickers. Dashboards. There is a definite need to find ways of creating ambient alerts. Things that only interrupt us when they have to. I think ambient findability is great concept as well. If I am typing in a document, and relevant resources on my hard drive, my network, my email, and the internet are being updated in a sidebar, they will be right at hand when I decide I need to look for something, it will have already been found.
There's so much to do. How can we be so bored?
Posted by Matt McKnight at 10:39 PM
Friday, October 14, 2005
Why are people such bad estimators?: "Painters say 5 days, it takes 8. Designers say 2 weeks, it takes 4. Programmers say 3 months, it takes 5. Government says it will take $X and it takes $XX. It’s been a very rare occasion (in my life, at least) that estimates have been anywhere near accurate. Even people in business for 20 years seem to have a bad time making accurate estimates. I realize an estimate is just a guess, but there’s a lot of bad guessing going around. What is it about people that make us such bad estimators?"
I think this idea has been around a long time- here's some top reasons why we're bad:
1) Humans are too optimistic.
2) While it may be possible to estimate how long it would take to do something if everything things went right, it's often difficult to estimate with error, interruptions, etc. that you don't have good data on.
3) What type of date is being given? What is a 5 day estimate? Is it the earliest date something could be possibly finished? Is the 50-50 date? The 90% date? You are talking about something that is stochastic, and would occur in a distribution.
4) The future does not always work in the way that the past did
And what to do about it:
1) Stop estimating
2) Adjust estimates based on progress (running features in a software project)
3) Present estimates as a probability distribution.
Posted by Matt McKnight at 3:25 PM
Thursday, October 13, 2005
Setting up a Rails Development Environment on Windows Using Eclipse
I think the best thing about code completion is not that it obviates the need to memorize tons of stuff, is that it reminds you of methods that exist on objects that you may have forgotten about. Maybe there is some kind of inbetween thing so that I can at least specify what type of object I want to be dealing with and get all of the methods and properties presented to me for easy clicking. Maybe I should be working on this...maybe not.
Posted by Matt McKnight at 3:28 PM
Remember the Milk: More TODO: "We must be getting really organized with all of the TODO list applications that are springing up. "
Remember the Milk
I can't decide if this is better than the free version of basecamp (one project limitation). It seems to have a couple of subtle bugs in the ajaxy aspects, but it is definitely a cool interface. It has the feature of sending email to add tasks, which works in backpack, but not basecamp (perhaps due the complexity of determining to which list the task should be added, which Remember the Milk solves with an inbox). I also like getting SMS messages or emails to my mobile when something is coming up. Anyway, it's good to see more apps in this realm. I think calendar integration is key. I need to find a good way to sync these things to ye olden blackberry until I get a more advanced mobile solution.
Posted by Matt McKnight at 12:53 PM
Falkands vs. Malvinas: "A confusing and confused article in the UK tabloid the Sun states that 'the British islands in the South Atlantic have been given Argentinian place names on the interactive Google Earth site.'
Well, in Maps the Spanish names are appended in parentheses. I have no problems with that, as it makes the map more useful to finding the islands when cross-referencing from other (Spanish-language) sources. (No access to Earth right now so if somebody could check...) "
It's interesting to see the reaction of people getting exposed to GIS data. The names of places can be very political. When I was giving a presentation in Morocco, they were disappointed to see that a country list in our application included "Western Sahara", which they rightly considered to be part of Morocco. Of course, we had not reviewed the list- it was an ISO list of country abbreviations.
To blame Google for any of these errors is idiotic- the data providers are the ones who made the decision, and they probably based on a list provided by an international standards body. While the name of place may seem to be the endorsement of a political belief, there's really no good way to be neutral and put all of the possible names for a place on a map and remain cartographically accurate.
This problem is doubly difficult when you are trying to produce a map for worldwide consumption. Do you call it Germany or Deutschland?
Posted by Matt McKnight at 10:00 AM
Wednesday, October 12, 2005
October 12, 2005:
"(The nattering scorekeepers of the BDUF/Agile beauty contest are now thoroughly confused. "Was that a vote for BDUF? Or Agile? What does he want? Can't he just take sides for once?!")"
Given that this method is almost word for word what is done in Planning Extreme Programming, I would say this is Agile. :-)
Big design up front isn't just about designing all of the features at once, you could still slip into doing iterations that are too big. And you could do 50 pages of UML models for a small iteration as well.
Posted by Matt McKnight at 4:13 PM
Monday, October 10, 2005
Playing with rails, one might note that it seems to be primarily database driven design (vs. domain driven design.) Why not generate the tables versus generating the model? There must be a good reason. I think the active record pattern is limiting for domains with complex structures that are best suited to object oriented design (whatever that means). While relational databases have some powerful features, they just aren't as good from a team/development, code maintenance perspective.
Posted by Matt McKnight at 8:59 PM
Monday, October 03, 2005
One of the oft mentioned advantages of SOA is that it provides a clean mechanism for code reuse. However, this is not strictly code reuse. In SOA, the reuser is reusing the actual running service. In code reuse, I take your library and embed it in my application. In service reuse, I call your live, running service from my application. In code reuse, if your application crashes, or the whole project is cancelled, there is no effect on me. In service reuse, I am entirely dependent upon the performance characteristics of your application. Think about the interdependencies ofa few three nines (99.9% available) applications- the availability of all of them drops. If one dies, they all could. Therefore, the "code reuse" argument for SOA is completely spurious. That's not to say that applications should never be integrated, but it shouldn't be done simply to reuse code.
The standard SOA response to dependency is indirection. In order to not create a hard dependency on your system, I use a third system (a service registry or directory) to look up the physical address of a service that offers the service your system provides. However, in your streamlined SOA, you have probably eliminated redundant applications, so there is nothing to switch to when your app is down. And now I am dependent on the service registry as well.
Monday, September 26, 2005
Posted by Matt McKnight at 4:36 PM
Tuesday, September 06, 2005
Martin Fowler has a link to Rebecca Parson's article on Enterprise Architects staying connected to development teams. This is an important thread of meaning in my thoughts on Service Oriented Gridlock- and the danger of the false architectures. My theory is that CIO groups, such as enterprise architects, should submit requirements to projects, and fund requirements to projects, such that they are prioritized along with other project requirements, such as ones actually requested by customers...
Posted by Matt McKnight at 11:51 AM
Monday, August 29, 2005
Just a brief note on the types of dates I have to deal with in software estimation.
Start date: Actually not as simple as it sounds. If you estimate something will take ten days, which ten days? I have seen a lot of arguing about when projects actually start.
Earliest date by which it can't be proven that it won't be done: DeMarco claims this is the easiest date to estimate, and the one most commonly used in scheduling. Frightening stuff.
Estimated completion date: Could be the product of some kind of parametric/statisical estimation, or engineered guess, etc. I think the pyschological effects of the estimated date are often underestimated. If the date seems unreasonably short or long, the behavior of the team will be affected. Often it is a huge mistake to express this as a single day, when the correct way of expressing the statistical truth is a probability range. Whenever I am asked for a 100% date, "when will we be guaranteed to get this set of scope delivered?", I just try to say something funny. The 100% date is meaningless, when so many projects are not completed.
Target or Goal Date: Usually a meaningless date created by management to inspire hard work, particularly if the previously mentioned estimated date is not good enough. Or, the date by which they will get whatever is done at that point in time. If you are going to attempt that strategy, you should begin doing timeboxed development from the start, so people know what to expect.
Date by which the project will be cancelled: Should be approximately equal to the day before the last date on which the project will still be able to have return on future investment- more ROFI than a replacement would (even if net ROI would be negative.) I like to ask the stakeholders for this one- and how many times have I heard that a crucial project that we are being asked to evaluate "can't be cancelled"? That kind of thinking is the kind of thinking that gets crucial projects cancelled!
Feature complete: The date by which the software has all of the features, but none of them actually work yet.
Actual completion date: Seldom reached. In development, is one ever really done? Even shrink-wrapped and shipped software usually has a patch or two ready to go before the first product hits the shelf.
This is why I prefer fixed increment, timeboxed development. It is so much easier to deal with scope slippages than time slippages. Scope estimation is the only way to go for the kind of projects I deal with.
Posted by Matt McKnight at 12:34 PM
Friday, August 26, 2005
Second in a series on Service Oriented Gridlock (SOG)...
If stovepipes are so terrible, why are there so many of them? Where did they come from? Well, the basic scenario is, the business wants some function, they call up the local Java, Excel VBA or Lotus Notes hacker and get it delivered to them. This can be a remarkably efficient way of getting things done. Someone wants something that is going to help them make more money, or accomplish their mission, and someone delivers it to them. The user is the primary focus of the development. Contrast this to the average enterprise project which spends a year gathering requirements, getting consensus from different groups about what priorities to do first, fighting about design and approved technologies among various senior architects, and then maybe delivers something that does about 50% of what the business need was, in a semi-usable form, and they probably don't even need it anymore. If I am a user, I want a stovepipe! I want a development project dedicated to me.
Posted by Matt McKnight at 9:25 PM
While you will find person after person who complains about the existence of stovepipes, applications that deliver function directly to the user and are not integrated with other systems, there is also a danger in becoming overly coupled to existing systems. Service Oriented Architecture (SOA) is touted as a way of ensuring that the coupling between systems is as loose as possible. However, moving from stovepipes to coupled systems, even relatively loosely coupled systems, represents a move from independent projects to dependent projects, and introduces a great deal of schedule risk into projects that are under development. A move from stovepipes to SOA can introduce what I refer to as Service Oriented Gridlock (SOG) to an enterprise, where no application can be deployed without affecting other applications, resulting in a dependency chain that greatly diminishes the ability of capabilities to be delivered to end users (the thing which stovepipes excel at doing).
This post will serve as the first of a series where I delve into factors that lead to SOG, explain a better process by which stovepipe applications can extended to provide services, and show how SOA can be achieved while still retaining the benefits of stovepipes.
Posted by Matt McKnight at 9:21 AM
Monday, August 22, 2005
Okay, Google Desktop is back in the lead over Yahoo! Desktop Search.
Yahoo! had the advantage when they basically made x2 available for free, but now Google has the Outlook toolbar and the amazing sidebar. The sidebar is kind of a competitor to another Yahoo! buy, Konfabulator, with the panes a sort of less curvy version of the widgets. Downloaded the API, but I haven't checked it out yet. Maybe after I finish up with the Code Jam.
Posted by Matt McKnight at 2:12 PM
Friday, August 19, 2005
Not too far removed from the Apple switch to Intel from IBM/PowerPC, Intel really seems to be trailing AMD in the server market. The 64 bit Opteron is selling far better than Itanium. AMD has beaten Intel to market by months with dual core server CPUs. It's gotten to the point where Dell is selling the desktop dual core chip, the Pentium D, in its server models, since the Xeon dual core doesn't seem to exist yet. Even more telling, server software vendors are advertising Opteron 64 bit compatibility.
The most entertaining thing about dual core is how it effects the licensing of software products that are licensed per processor. IBM has started to relent, probably because they want to sell the dual core AMD machines while Dell waits for Intel. Oracle on the other hand, still wants double the cash for letting you use an upgraded processor capability that required no changes to their code.
So, I've got to buy a new server this weekend. Dual Core 64...
Sent from my BlackBerry Wireless Handheld
Posted by Matt McKnight at 9:31 AM
Thursday, August 18, 2005
I find the port blocking of my ISP, Cox Communications, to be a little confusing. Why do they block port 80, but not 443? And the claim not to block port 81, but I can't get to port 81...why? It's so difficult to debug when they have an unclear policy.
Still it's better than the old days.
Posted by Matt McKnight at 11:27 PM
Monday, August 15, 2005
There is something fundamentally weird about the existence of c#. According to monster.com and book sales, it's not popular. I think those numbers are skewed a bit because it a lot of HR and hiring managers just ask for “.net”. I don't know how someone could have skills related to the VM in general, but I suppose there are a few bytecode hackers out there that could write “.net”.
As I understand it, no one wanted them to fork Java, like they tried with J#, so they had one of the programming language greats whip up something similar with a different name.
Why does microsoft want a VM anyway? Won't c++ run faster? Were they actually counting on mono to provide write once, run (or crash) anywhere support? I think there are better ways of doing managed code.
So, my days of COM hacking are getting behind me enough that iUnknown is becoming I unknow. (Ugh) Still, I have fondness for the power of the monoculture approach. Why no one has written a javac for the .net vm is interesting...maybe I need to google that before I say it's true.
C# just isn't worth it. If you are a duffer you do vb.net and that's great. If you know what you are doing, you do c++. If your boss won't let you use java, you use c#.
If I had to choose between the three, I'd go for one that will be here in 10 years.
Sent from my BlackBerry Wireless Handheld
Posted by Matt McKnight at 6:49 PM
I signed up for the O'Reilly Connection site. I am hoping it will be a way to connect with some top developers. Unfortunately, we have some rather severe requirements for people that want to work on some of our jobs, so my guess is that there will be only a few people who will be eligible. I don't know if sites like this work that well. I also tried Yahoo!360, but that seemed too general. Why would I bother putting content there when it is so difficult to access, but not targeted to any specific group? I think once the content is identified as being for a particular target market, it does make sense to limit access. Limiting access gives people the freedom to reveal a little bit more about themselves, without opening the door to people who would use it against them. Well, I guess it actually does leave the door open, but if someone is being bad, at least the door can be closed to them.
Posted by Matt McKnight at 8:25 AM
Friday, August 12, 2005
Over time I have been moving much further that I ever thought I would away from a purist OO mentality. The difficulty of programmatically generating code to run in web browsers has been a big source of that. I think it really has a lot to do with the heterogenous programming toolset need to do anything remotely interesting in a web application. Generating DHMTL from XSLT or JSP, as referenced by Java code is just a messy endeavor. Scripty hacks are a necessity.
Thursday, August 11, 2005
The capability to post to things like this from a mobile device is a real improvement. After years of not being able to carry a wireless device due to workplace policies, constant connectivity is still new to me. I am liking it.
Sent from my BlackBerry Wireless Handheld
Posted by Matt McKnight at 9:22 PM
Maybe it's not so great to find vacuuming fun for long. I think people who are in the position where the things that they find fun are their work. But vacuuming is definitely going to the robots. Not a growth field over the next 30 years.
Posted by Matt McKnight at 11:07 AM
I am making a another focused attempt to be more productive. 5 short project plans due in the next 6 days. It will be an interesting test to see if I can do a reasonable job on those, and handle spending some time on the things that I really want to do.
Posted by Matt McKnight at 10:50 AM
Wednesday, August 10, 2005
It is difficult to keep pace with the ever advancing wave of things other people are doing while trying to do things oneself. Indeed, just reading about all of the other things people are doing makes me wonder where they find the time, they must not be keeping up with what everyone else is doing.... I think there needs to be a shift in the balance in my life towards the doing side, away from the keeping up side.
This was triggered by having feedreader deliver to me a description someone having done a part of what I was trying to do
Posted by Matt McKnight at 1:04 PM