Friday, September 12, 2003

There are lots of lectures going on at Microsoft...many recorded talks online publicly at the Multi-University/Research Lectures project.  via[Curiosity is bliss] via [Thinking In .NET] This talk caught my attention: Social Data Mining: Approach, Systems, Results. We’ve seen how easy it is to de-anonymize content by simply using Google. I wonder what would be the impact on privacy if more powerful systems become broadly available. (Note to self – find a hour to watch this one)

Monday, September 08, 2003

If you can read this, it means that both NewsGator and Radio are up on my new box. Contrary to what might seem going from 500Mhz/512Mb to 2.6GHz/1Gb does not makes everything 5 times faster J

Monday, August 04, 2003

Whoa! Novell has purchased Ximian. Since Ximian is the home of the Mono project, that puts Novell in the cross-platform CLR business. Very very interesting. Imagine a future where you write a C# application using an IDE from Borland, deploy it on Linux, and use LDAP and other enterprise services implemented by Novell on top of Linux. Who said competition in the software industry was dead? [Larkware] Whoa indeed!

Friday, August 01, 2003

Robert Scoble points to new version of famous J2EE vs. .NET performance report by Middleware Company. To summarize the summary, the fastest J2EE server delivers similar performance numbers as .NET running PetStore web app. .NET is 200% faster at running SOAP Web Services. What I found really impressive in the original study is differences in productivity numbers. There’s no word on a rematch between J2EE and .NET with respect to productivity. My tentative interpretation is that previous conclusions still stand.

Wednesday, July 30, 2003

From interview with Brian Kernighan (via Chris): Aleksey Dolya: You are a well-known expert in practical programming. Does it differ from theoretical and research programming? Brian Kernighan: As the great American philosopher Yogi Berra is reputed to have said, "In theory, there is no difference between theory and practice. In practice, there is." I'm not sure what theoretical programming might be, but code that can't be executed on a computer is unlikely to work and thus isn't terribly useful except as a thought exercise. Research programming might mean software written as a prototype or [used] to verify that some concept can be made to work. There, the difference is that one can cut lots of corners: don't worry about errors, ignore potential hazards, provide no user interface, skip documentation and, of course, do no maintenance. In that sense, research programming is vastly easier than writing a program that will be used by many people over a long period of time. Someone (Fred Brooks, in The Mythical Man Month, perhaps) once said that it is at least an order of magnitude more work to do production software than a prototype. I think he's wrong by at least an order of magnitude. Read the entire interview for other great insights from a great man.

Wednesday, July 09, 2003

IBM is unveiling Wednesday new tools to help corporations make sure their confidential information is only seen by authorized employees. [News.com] Arvind Krishna, Tivoli Software : "These will help enterprises and governments manage the privacy of the data they collect, there is nothing in terms of technology to help them do that today.'' Excuse me???

Monday, June 30, 2003

When to re-architect?   Luke Hofmann in his book “Beyond Software Architecture” gives a rule of thumb as to when to consider changing the architecture. The rule says that that says that you should consider the venture if the re-architecture would take half of your current team working for 1 year.   I would approach giving the answer this question a bit differently. You should consider re-architecting every time one of the success factors of the architecture isn’t working for you. Any one of the points in the section “Why architecture matters” (plus the platform factor) should be considered as alarm bell.   To give a real-life example, a large scale 3D production system had to be re-architected because several of the success factors have seized to be true. Here are examples of some of those factors. The old architecture made it difficult to change things customers wanted changed. The old architecture has lost its unfair advantage the system enjoyed over the years. There was also the platform factor. The platform the system ran on didn’t match with the changing realities of the marketplace. Support the aging platform was to run the risk of killing all revenues from the product. The decision to re-architect was the right one. In fact, it should have been taken earlier. It took most of the development team to re-architect the system over the 4 years of development. Through this time, a small development group was tasked with maintaining the old system.   Another example from a software company in business of developing online security services for consumers. While current architecture powered their product, the decision to re-architect was taken after it became apparent several success factors weren’t stacked in their favor. Looking at costs of sustaining current architecture it became clear that the system need to be more profitable architecture. The profitability factor is closely related to the cost of changes. The management realized that is would be too costly to attempt to execute the product roadmap on the current architecture. In order words, the feature customers wanted were just too difficult to implement. Then there was the platform factor. The old architecture was using a collection of open source pieces (ex: MySQL database) that were difficult to keep in the context of all the new features customers were asking. In this case, the decision to re-architect was taken even though it will impact the entire development team, even require bringing new talent.      The book “Beyond Software Architecture” by Luke Hofmann provides a good answer to this question of why software architecture matters and essentially enumerates the success factors of architecture: -         Longevity. The architecture will outlast most of the code, and can even sometimes survive changes in business models. -         Stability. You cannot claim you have architecture unless it is stable. -         Degree and nature to change. The architecture should successfully respond to changes to things like functionality, priorities of different feature sets. -         Profitability. The architecture is successful when its profitable. -         Social Structure. The architecture fits well with people who work with it. -         Boundaries defined. The architecture that clearly defines what “in” or “out”. What kind of extensibility is supported or not.   (The book also includes sustainable, unfair advantage as created by product architecture. I disagree that a successful architecture must present an unfair advantage or be hard to duplicate. At times, the unfair advantage of the business model could indeed be based on the architecture, but oftentimes successful businesses are based on classic well-known architectures.)   After reading though the list of success factors I was tempted to add one more. The Platform Architecture isn’t created in the vacuum and will always be based on some platform. A platform could be an OS, a database server, a runtime (Java Virtual Machine or .NET Common Language Runtime) or other foundation pieces. Even if you successfully define the boundaries of your system, the will be critical pieces that would fall outside of your architecture. Any non-trivial architecture benefits from numerous services of the platform. Once the platform is picked, its evolution will most likely be outside of your control. Because of the longevity of the architecture, you will often want the system to run on newer versions of the platform to come long after you’ve completed the architecture. The platform will always have the ability to ultimately kill the system or sustain it over the long run.      Beyond Software Architecture by Luke Hohmann. I bought this book based on several factors. First of all, I think that learning more about interrelationships between marketing and software engineering should be important for anyone interested in creating successful software products. Secondly, I’ve found that the first book in AW Martin Fowler Signature Series (Patterns of Enterprise Application Architecture) a must-have reference for every serious software architect. When I first opened this book I was very impressed by the number of high-profile people endorsing it and giving it praise. Exited, I’ve said to myself and others that I have great expectations for this book – I will learn a great deal from unique experience of the author. After all, not every author can speak from the position of software architect, product manager, marketing professional, software developer, development manager, consultant and teacher.   When I started reading, I began to notice that statements made by the author were correct, but often too simplistic, trivial or incomplete. Not to worry – I though to myself. The author must be preparing the reader for in-depth insight on “how to build winning solutions”. So I’ve continued reading.   By the third of the book I’ve stopped taking this thing seriously. I’ve realized that the author has chosen to touch on every single topic relevant to a software development organization. The trouble is, the author fails to tell anything that would not be considered trivial by any experienced software professional. Opening the book at random you’d stumble on sentences such as “The business plan distinguishes itself from all other development documents at it is the foundation for all the work associated with the product.” Correct, but fairly content-free.   And then, there are numerous text boxes that break-up the prose by telling a story from author’s experience. Most of those stories tell about how the author single-handedly saved the day by being super clever, super insightful and generally super smart. Great stuff for someone who considers hiring the author, but most of those examples bring little in terms of in-depth analysis of the issue.   The bottom line is, if you’ve spend a few years developing commercial software – don’t bother reading this book, you probably already know the things this book talks about. And if not, you’ll be much better off picking a more focused book that covers a particular topic of interest. Would I recommend this book to a student? No. In fact, the book is even less useful for a student because it covers too broad of an area without giving the reader in-depth knowledge in anything. Perhaps the only case where the book would be useful is for someone who wants a high-level overview of the issues that architects, senior developers and product managers worry about.   One good thing that this book introduces (in appendix) is the idea of using patters for things beyond software design. The idea of capturing “design patterns” for business and marketing issues isn’t new, but definitely not completely explored or understood.   The book attempts to close the gap between business and technology. Not many people have had the right experience to do so and be able to write well about it. The best (even a bit dated) book I’ve read on the subject remains “High-Tech Ventures” by Gordon Bell.      You are Neo, from "The Matrix." You display a perfect fusion of heroism and compassion. What Matrix Persona Are You? brought to you by Quizilla [via TheArchitect]

Site Statistics

© Copyright 2003 Alexis Smirnov. Last update: 9/12/2003; 11:49:38 AM.