A key to Microsoft's success in the 80s and 90s was that software enterpreneurs could easily develop for MS-DOS and Windows and get in front of their customers, and that in turn strengthened Microsoft. Allowing entrepreneurs to make money by building on top of your platform cements your platform's place in computing. Google has released a few small APIs and Google Gadgets, but never attempted to introduce a major platform.

Since the days when GMail alerted everyone that Google was more than just Internet search, Google seems to have branched into a dizzying array of software niches, rarely throwing a knockout punch though. Google Docs is still a very weak product and Froogle was dropped in favor of Product Search, but in general their products are fast and have a lot of potential.

More

A recent example of thought grooves at work -- or groupthink -- was spawned by Joel's post where he railed against anonymous posting as the bane of discussion groups.

"Frankly if every anonymous post disappeared from the Joel on Software discussion group, the overall quality of the conversation would go up, way up, and the discussion would be way more interesting."

I'm a fan of Joel's writings, but in this case he couldn't be more wrong. Funny thing is how he could start with Dave Winer's argument about personal blog comments (which I whole-heartedly agree with) and then draw the wrong conclusion about forum posts and have all of the resulting discussions fall completely into this thought groove.

More

System integration is simply the most difficult part of programming. The engineering challenge of bringing together components to build a good product is often underestimated.

Get this: developing software will just be a matter of plugging intelligent components together.

This claim comes up often in discussions about the current and future state of software development. It is the recurring dream of component-based development where pieces of software can essentially figure out what a programmer wants because other programmers have planned ahead. It is the wishful thinking of architecture astronauts and people who trivialize the hands-on design and redesign stages of development.

More

If you have 3 or more ideas it feels like you are bursting with ideas. If you have 10 or more ideas you'll probably say you have a "million" ideas. Why? Because ideas are like trees with branches reaching out into the sky in so many directions. Each idea has so many possibilities it doesn't seem to have boundaries, and so the effect of ideas in your brain is overwhelming. For budding entrepreneurs with active imaginations it can be hard to see the forest for the trees.

Some will insist that a good idea is priceless. But I am talking about business ideas. A business idea creatively connects your real circumstances with a real possibility of turning a profit. Such an idea is valuable only in the sense that the first step in a marathon is essential.

More

the key to achieving business success
...is to be good at it.

Are you tired of smug successful people expanding their fame and success by publishing articles about how to become successful?

And it all comes down to this: be really good at it! How helpful is that, really? Oh yes, they mix it up with lots of catchy turns of phrase, like "Fail your way forward" suggesting that they made lots of mistakes along the way. Did they really? I kind of doubt it. I think their mistakes are just little post-it notes on their unstoppable march to a destiny of success.

More

I worked for a contractor in the Pentagon Army Budget Office in and around 1995. Few of my projects have been as successful as this one, and it was also unique for me because I spent a lot of time working directly with the customers, learning their way of doing business, i.e. collecting requirements.

The ABO has an annual schedule that revolves around U.S. budget cycles, and they have both civilian and military personel working together on budget coordination. As I recall there was a staff of about 5 and then about 15 analysts would be there at headquarters during crunch time, and many more people were involved. The coordination in the ABO involved gathering and working with lots of forms filled out by people at the field offices as well as the decisions made in budget meetings.

More

"Agile" and "Iterative" techniques have gained favor and even to some extent become part of the software development establishment. But they have not impacted large (team of 50+) information technology projects which gravitate to variants of the "Waterfall" methodology and BDUF (Big Design Up Front). From Wikipedia:

Agile methods are often characterized as being at the opposite end of the spectrum from "plan-driven" or "disciplined" methodologies. This distinction is misleading, as it implies that agile methods are "unplanned" or "undisciplined." A more accurate distinction is to say that methods exist on a continuum from "adaptive" to "predictive."

Developers tend to agree that the more adaptive methodologies don't scale well to large projects. I am proposing the Market Paradigm as a means to scaling these adpative techniques to large projects.

More

If your database consists of a boatload of rows, you might call it a rowboat.

In this one short article I cover all the essentials of a complete multi-session database design. I haven't studied any database theory since college (1991), and I'm not even sure I did then -- although I do have a Computer Science degree. So I am writing this entirely off the cuff based on experiences with databases and my computer science knowledge.

More

Working in the software industry has great potential for allowing one to go and experience the tropical island life. As a programmer you might find an opportunity to work on an island like I did, or as a Micro-ISV owner and/or independent consultant who just needs Internet access you could write your own ticket and spend your days with a laptop at the beachside bar. In the latter case, here is my recommendation: go for six month stretches on a tourist visa rather than officially moving there.

As someone who grew up with the moderately cold winters of southern Ontario, Canada, I always thought it would be great to live on a hot tropical beach somewhere. I'd been working as a C/C++ programmer in Virginia for 5 years after college when the opportunity presented itself.

More

In the software industry, real pain is what makes you want to strangle someone at the company that made the software you are using; real pain is when you are losing money because you can't get your systems to integrate knowledge and manpower; real pain is when software breaks down or is unnecessarily susceptible to human error; real pain is when all of the available solutions have one significant shortcoming for your needs like not supporting your platform or too large a footprint. All these real pains create tremendous opportunities for startups.

The pain that my current product CMarkup solves is the complexity and overhead of XML solutions for simple XML purposes. Experienced and practical C++ programmers take one look at those big things out there and say "Yuck! There's got to be something small and easy for such a trivial problem" and then they go online and find my product.

But CMarkup was just a nice accident as I explained in I See Markup, Part 3 - Transition To Commercial Product. The idea I introduced in my last post "Here Is My Idea" is the peer to peer spreadsheet idea that was in my mind when I started my company in 1999, though I have never brought it to market.

More

Yeah, selling the idea is difficult. But, it's not impossible. Just start a blog and explain why your idea is better than Microsoft's or Google's.

I started this blog six months ago to do just what Robert Scoble is saying: to explain why my idea is so good. I don't want venture capital, but I do want to capture the imaginations of colleagues and first adopters. I have some white papers and a prototype from about 5 years ago that I only showed under non-disclosure at the time, but now I intend to explain it all in this blog eventually. That old assumption that it needed to be kept secret has long since vanished.

My idea brings together spreadsheets, XML and peer to peer technology. Stay tuned to this blog as I expand on it.

More

Software development is a problem solving business. But it seems we sometimes can't even apply common sense. This is a true story of how the leadership of a large IT project (team of 100+) went through various stages of denial and last ditch adjustment on a long drawn out death march.

To make a large problem manageable you generally have to break it down into smaller problems and let separate teams handle the smaller problems. Of course you need to break it down along lines that allow the smaller problems to be solved individually, otherwise you have not really broken it down at all.

More

The first car in history was not built on an assembly line. In fact, the first car of any newly designed model is still not built on an assembly line. Well that goes without saying right? Why then do the leads on large projects (team of 50+) try to build the assembly line before they produce their first car? In fact, why do they try to use an assembly line at all when every car is going to be different?

Well okay, may be it is not exactly an assembly line (although some have been known to use the term), they are just trying to define the architectural framework, i.e. the way that modules will work together and re-use common parts. But, to borrow Tim Bray's words, this attempt to design the framework beforehand fails in its "overreaching completism, trying to be, in Gall's terms, 'a complex system designed from scratch.'"

More

Microsoft bloggers have a new star in their midst with Michael Kaplan who began his prolific blog over a year ago. Praised by Joel Spolsky, Michael is a natural blogger since he was always active in the newsgroups and wrote a highly regarded book some time ago too. I don't know if it is a good thing to shamelessly heap more praise on him, but it shouldn't do much harm because no one will know about it: I have at most 2 or 3 people reading my blog (and one of them is me)! Anyway, Michael is hands down my favorite blogger of 2005.

The theme of his blog, Sorting It All Out, is internationalization with some straying into adventures at conferences and travels and there is a supporting cast of regulars commenting, most noteably Mihai Nita, an Internationalization MVP who is a great contributor. It might strike one at first as very Windows-centric and technical, but actually his subject area looks outward to the cultures of the world as well as the Unicode Consortium, so he escapes the Microsoft-only and techy pigeon holes too.

More

This is the story of my product CMarkup.

A Chai Wallah is a person who sells tea on the street corner in India pouring it in a tall narrow stream from pot to clay cup with great aplomb. India is the world mecca of small business and there the business owner whether selling chai, fruit, fish or clothing, often does it with evident glee. That is because (there especially) if you don't have great customer relations someone else will gladly take your place. But aside from that, there really is something universally exciting about selling a product for significantly more than the cost of the raw expenses and having happy participants on both sides of the transaction. There is also an accompanying joy in displaying your craft to your customers.

More

This is the story of my product CMarkup.

All products compromise, big budget or small. Some of those compromises are easier to make than others. Of all the strategies for CMarkup, one of them deserves special attention because it was the most troubling and yet it turned out by luck to be brilliant too.

May be this will give others inspiration that their biggest weakness could be their biggest strength after all.

More

This is the story of my product CMarkup.

In summary so far, I wrote a small XML parser for our project (Part 1), it turned out to be useful and at the same time the XML industry was a big stinking mess (Part 2), and this provided an opportunity to start selling it (Part 3).

If you buy coffee at coffee shops regularly, you become sensitive to how well-run a particular shop is. I admit that when I go to get my coffee I am like a New Yorker; I really don't want anyone wasting my time. But once I get my coffee it is a different story, it is a time to relax, to sit and reflect. I sometimes spend that time reflecting on how well-run the coffee shop is.

My goal with CMarkup is to be that well-run coffee shop. Nothing fancy, just get the important things done.

More

This is the story of my product CMarkup.

When Joel of Joel on Software began writing some five years ago about how he was going to run a successful startup, I found it inspiring to imagine that building a successful software company was just a matter of being smart about it. I am also inspired by the fact that my own uncle actually started selling fish tank lighting systems (of all things!) on the Internet at A H Supply as an offshoot of a hobby and created a successful full-time business.

It seems that people never know quite how they are going to get into business before they do. It doesn't matter how much planning you do, you have to be a bit of an opportunist as well.

More

This is the story of my product CMarkup.

Watching the way XML was becoming a part of the software industry was like seeing my favorite elected official getting mauled by capitol hill and the media.

In 1999, many of the ways the XML industry was growing seemed really troublesome. On the large project team where I was working, there was pressure to use Microsoft's XML solution. So I created a version of CMarkup that wrapped MSXML with the easy methods of CMarkup. This was used in stress tests on our customer sites, so we found MSXML to be solid for our purposes. However, as a separate component it involved deployment issues and probably used more system resources than necessary.

More

This is the story of my product CMarkup.

To a C programmer accustomed to dealing with strings and files, the idea of using a huge parsing library or giant component to handle a little XML is like using a helicopter to make a run to the grocery store.

In January 1999 I started working as a subcontractor on a large government IT project. Like many government IT projects it was meant to streamline a huge number of legacy and upgraded systems across the world. Anyway, we were looking at XML as a technology, and I discovered as other developers did that although it was a great thing it was not all it was hyped up to be. There were no robust XML products that could be deployed across an array of platforms and configurations that would enhance interoperability without requiring significant setup, configuration and changes to the way the systems were used.

More

I believe in adhering to the XML standard but I just want to call attention to ridiculous things that are experienced by many programmers as part and parcel of XML.

Doing everything but your original task

XML comes with strings attached: if you use XML you are supposed to be drafted as a soldier in an epic battle for well-formed markup around the globe. They don't tell you the significance of that up front. They lure you in with a hint of a panacea, and vague notions of a host of accompanying benefits that come to those who buy into the whole XML way of doing things.

More

My product CMarkup can sometimes allow you to parse ill-formed XML. I definitely do not encourage anyone to intentionally produce ill-formed XML but the bottom line is that sometimes you don't have control over the "XML" you need to consume.

Specification versus reality

There is a row of identical new houses all built to the same specification, and a carpenter is tasked to put together and install built-in shelves in an alcove in each of the homes. Would the carpenter take the measurements from the specification and go away and cut all the materials to the exact measurements and even preassemble some parts? No, the carpenter would at least measure some of the houses to get an idea of potential variations, and wait to cut the shelves to the exact measurements on site.

More

Large government software contracts are in some respects like large highway interchange construction projects. A lot of money is allocated, there is a bidding process, and one or a team of contractors wins the contract which is scheduled to take several years. Unfortunately, that is where the similarities end.

A large highway interchange construction project is based on a much more mature industry with a much more concrete goal: roads and overpasses that meet well-established specifications for roads and overpasses and traffic that flows. To imagine what a large government software contract is, think of what the same highway interchange project would be like if they did not know the terrain, only that it was possibly a mixture of land, sea and cliffs. Add to that, there are no reliable maps of the roads leading into the construction zone, just numerous rumours of traffic jams. Add to that, the exact types of roads and overpasses required may or may not have ever been built before.

More

An article in FORTUNE - Small Business called Getting to Know You by Richard McGill Murphy describes how Microsoft is using anthropologists to help develop Office Small Business Accounting 2006.

there is a certain correspondence between Microsoft's research agenda and the work of those old-time anthropologists, many of whom were funded by colonial governments that needed to understand their native subjects in order to rule them more effectively. The modern version of this knowledge-power dynamic is Microsoft, a multinational technology colossus that hires anthropologists who study the natives in order to sell them more software.

More

Mountains of Discarded Software is an essay I wrote in 1999 posted here in four parts. This final part challenges the software developer to get bold and courageous, not with the latest technologies, but with what might seem like radical design choices that reach directly and naturally into the customer's world.

Now that I have argued that there is "another way", I will return to what we as developers can do in the design process. Since the customers are not trained to understand what computers can do for them, WE need to understand what computers can do for them! We design software by using our analysts to understand the customer, and our programmers to understand the technologies, and we try to bridge that gap between what the customer does and what will make it easier.

More

Mountains of Discarded Software is an essay I wrote in 1999 posted here in four parts. This part tries to go "outside of the box" and challenge you with an unorthodox way of approaching design in an example budget coordination work-flow scenario.

When laying down a high-level design the foremost question should be: "what is the computer good at?" Anything that seems like a daunting task for the computer is suspect. For example, the difficulty of managing user roles and permissions is evidenced by the problems we have all had with getting access to something when we need it and have every reason to it, but the computer just doesn't seem to understand!

More

Mountains of Discarded Software is an essay I wrote in 1999 posted here in four parts. This part describes the problem encountered during design and requirements analysis when the customer and the software developer proceed according to percieved standard practice and how that fails them.

When the contract is awarded, the customer has only a vague idea of what is needed. As the overall design takes shape, it is standard practice for the software developer to ask the customer to sign off on requirements. Unfortunately it is often a painful process illuminating the disconnection between these parties.

More

Mountains of Discarded Software is an essay I wrote in 1999 but never made public due I guess to feeling I needed to tow the line as a subcontractor on a Government contract or perhaps just because I had no ready forum to publish it (blogging wasn't big yet). It is posted here in four parts. After a few years of working closely with customers in the Department of Defense, I began to see a problem with the bigger picture. Immense inefficiencies had become engrained in the system despite so many good intentions and hard working people. To this day, though I am currently working on commercial software, one of the goals I am most passionate about is introducing a platform to improve budget system efficiencies across the U.S. program budget system. Even though I wrote this 6 years ago, it remains just as relevant today.

More

I have been showing Google Earth to everyone since I first installed it in June. I've always been fascinated by maps, but everyone I've shown it to is absolutely enthusiastically amazed too. Even if you have seen satellite images in one of the Internet map sites, you will not be prepared for this. Note that you will want to have a nice graphics card and fast Internet connection for the best results. It is a desktop application with a quick simple install. As you explore the globe, it seamlessly loads Google's data for the viewed locations via the Internet.

More