Middle Class Software

The middle class is where most of society resides. It's where most political campaigns take aim, and if they don't, they'll look as though they don't care. Why doesn't software do the same thing? It's funny how software can take control over every aspect of our lives, and yet, we're not all that concerned with accessible software. I don't mean accessible from a standards perspective for users with disabilities — that's an entirely different problem. In this context, I'm referring to software that's inaccessible even to those that fortunate enough not to be disabled. It's a problem, I think, that there is a ton of good code produced in various open source communities, and it doesn't get the kind of audience that it should. The reasons aren't plentiful, but not straightforward, because if they were, we would simply address these issues. But I'm sure that if we could try to identify the middle class software user, your typical every day user that might want to use your software, we could take steps in making the world of computing more appealing.

How To Gamble With Software

Casinos are a place of pure excitement — each visit an exercise in frenzied fun.  The short-lived thrill of a large payout is tough to beat.  But then, it's over.  Better luck next time.  Who could possibly enjoy forfeiting their money like this?  Sure, you have great earning potential, but the odds are simply not in your favor.

Gambling, casinos, compulsive habits — software?  Yes.  And it's easier than you think to make ludicrous decisions during the development of software products.  Do they seem out to lunch at the time?  Of course not.  You're a good developer with common sense.  You've toured the neighborhood and have street smarts.  And yet, you still make bets that aren't in your favor.

The Big Picture
The largest bet we place on our software projects is whether we do the project at all.  What we're setting out to do, to sell, and to solve — this is by far the riskiest job.  At inception, there is no product.  There's no project either.  Because, at this point, everything is still just an idea.  At this stage, we're still outside of the casino doors.

Jumping from inception to real projects is the ultimate dice roll.  Here, a bold statement is made.  We will deliver the best open source project management system.  We will turn around this customer portal in six months.  We will sell enough of this video editing software to stay alive for the next six months.  A gamble is only a gamble because we've set a goal.  A tangible to aim for.  Without a goal, it cannot be missed — and so you've nothing to lose.

This, in my mind, begs the question — are we better off not setting goals for software projects in the first place?  Could we better operate as a software development team if the bar is lowered, if the threat of failure is eliminated?  Of course, lowering the pressure — delivering production-ready code fast — endows a degree of competitiveness.  Without predefined goals, and conversely, consequences of not meeting those goals, we're more inclined to make the right decisions during the development effort.  More focus is targeted at product design.  We can evaluate alternatives, something that all too often evaporates in the face of pressure to deliver a sound product or service.

Is there a need to make big-picture gambles?  Are there any rewards to setting goals and trying to exceed them?  Or should we assume a passive attitude and simply do the right thing in terms of what we, the developers, think is right?  The trouble is, not setting a tone — a sense of urgency on the project will ultimately dilute the pace of progress.  How can you measure progress if you haven't a target to aim for?

Gambling Versus Guessing
I would argue that the big picture gamble — the decision to build and to solve and to move forward — is inevitable.  The truth is, there is no such thing as safe software development with no risk because humans are responsible for building it.  Humans are living organisms who only have so much time to devote — there are only 24 hours in a day.  We build software because of an insatiable urge to build things.  Not random things, but functional tools that serve a purpose and are of appreciable value.  Is the software, when finished, going to be of relevance — to yourself or to anyone else?  This is a gamble that is unavoidable — it's sown into the fabric of writing code.

The trouble for me, is, how do you know what makes a great software product?  What really stands out above and beyond anything else?  There is obviously something that makes this a reality for software projects because success stories are plentiful.  But they do pale in comparison to failed software development efforts.  These failed for there own unique reasons.  There wasn't enough consumer adoption.  There wasn't enough funding to support the continued development.  The list goes on, but I do think there is one dimension shared between those that succeed and those that do not.

Gambling in software development terms isn't exactly the same as gambling in casinos.  If you're hitting a slot machine, you've no control over the outcome.  This is a pure gamble, win or lose.  We're guessing that we'll win.  Software development at least gives us some indicators — the kind that can assist with making informed, calculated decisions before we place our bets.  This is better than guessing.

So to avoid becoming a statistic in favor of not starting a software project due to likelihood of failure, it's best to limit guessing.  Guessing that something will just work.  Guessing that your potential customers have a real need for your product and will applaud it.  Guessing that using library abc over library xyz will be beneficial.  These are all things that we can research and deliberate over.  Not doing so means you're guessing, and doing so will lead to diminished control over the direction of your project.  Sure, both successful and unsuccessful software projects make big gambles.  Some win, and win big, others, not so much.  But the ones who win big undoubtedly restrain the amount of guesswork — much more so than their counterparts.

Staying The Course

During the development life cycle of a software product, how does your team veering off into unknown territory?  Scope creep — as we're taught early on as software developers — is one obstacle plaguing software projects.  This is where even small, minute changes, if allowed to accumulate, yield something something maligned with the original goal.

On the other hand, how does your product evolve if you're not allowed to innovate?  Because, often enough, late breaking ideas coalesce during development — not after it's finished, not during requirements gathering — but while you're coding.  Taking these great ideas that pop into mind and pushing them out until a later date — just so you can stick with your plan — kills their momentum.

So it turns out that staying the course is a difficult thing to do.  You need a concise goal and commitment to fulfill it — by keeping out unnecessary features and making sure the thing ships on time.  Is it possible to sneak stuff in while honoring your stipulations to the project?

No time wasted
Time is of the essence for software development — do more with less.  Otherwise, the bigger guys, your competition, will hit the mark.  Freedom to muck around with experimental concepts isn't exactly palpable come crunch time — code needs to be rock solid, ready to pass any QA tests and make it into a production environment.

The question is — how do you make resilient code while under time pressure?  That is a challenge and why writing code professionally is difficult — you have no such freedoms.  You can't devise a selection of alternative solutions and evaluate the best one.  There is no time.  You have to go with what works initially and, if luck finds you, you'll get a chance to refactor and improve your code later on.  That is a big if, of course.  How often do you put TODOs in your comments that never go away?

So if you can understand why time is so important during the fragile embryonic development stage of a project, perhaps you can formulate better ways to do more with it.  Better ways to improve your coding standards.

One way to look at it is this — it isn't so much a problem with time as much as it is with functionality — the behavior of your software.  Because what your software does dictates how much time you'll need to implement it.  Part of being agile is doing small development-release iterations — short time frames.  So this means that the scheduled features need to take into account the timeline, and not the other way around.  I think this is a major breakthrough in how we do software — understanding that yes, people do expect code on a regular basis and yes, there is a fixed number of accomplishments teams can make in that interval.

Time is of the essence, not the software.  Considering the amount of time you have to do something — before it's considered production-ready and hits the shelves — is perhaps the first and foremost determinant of any project's success.  If the interval means only small, minute changes can be done, then the reality is, the schedule needs to change, not the way we write code.

What does your software do?
You'd be surprised — I find I do this myself — how often I hear developers talk about what their software will do when asked what it does.  I find it interesting that we're so fixated on the future — how do we make sure our software is future-proof?  The problem with that sentiment is that it doesn't support the notion of problem-solving aspired software development.

We all know that mission statements can be loathsome at times — but they can be a powerful tool in staying focused on solving the problem at hand.  All software solves a particular problem — if the mission of the software is to solve the problem, or to at lease appease it to some degree, then you should be able to state how it'll do that.  What you need is a consolidated, fundamental kernel that your software derives from — the problem and what your software does about it.

This makes describing what your software does much easier.  With a declarative foundation of what your software does, you can reference it throughout the entire lifespan of the project.  Having such an immutable artifact means that you can put it to good use when it comes time to evaluate what features are going to make it in and which don't.  Consider whether the proposed feature will have a positive impact on your mission statement before spending any real time on it.  Having said that, we've now got two primordial tools for staying the course — the mission statement and the knowledge that time is of the essence.

Some things add up
How are we to treat these axiomatic rules — or restrictions — of software development?  The two seem very prohibitive to making any sort of progress whatsoever.  On the one hand, we've got time working against us — pushing forward, never slowing, always diminishing what resources we do have.  On the other, we've got a bombardment of requests and other issues to figure out — all while making something that solves a particular problem.

We need to innovate around these constraints.  That is, instead of trying to beat the competition by jumping ahead and pretending that time isn't of the essence or that building new features that don't support the mission statement, we should stay the course.  Innovation means recognizing these constraints and beating the odds.

Modeling Existing Systems

Modeling software is an expensive activity. Building software models can be expensive for a multitude of reasons. The most obvious being the time lost for unsuccessful designs. Software models take time to put together. Unless you are sketching, the goal being to not spend a lot of time on them. Contrast this with a failed initial software implementation with no up-front modeling. There is a high probability of reusable software components that may be salvaged from the failure. Developers tend to become fixated on functional software. If something that at least somewhat functional comes out of a disaster, it will still help with morale.

So, if detailed modeling has no place in up-front software development, does it have any place in software development? Creating a detailed model of an existing software system may prove valuable. The key to modeling existing software systems is to pin-point exactly where the design has gone wrong. This is nearly impossible to spot during initial development. Especially under time constraints when the priority of design takes a back seat in favor of a functional system.

The obvious drawback to up-front modeling in software development is that promotes a waterfall approach. The waterfall approach doesn't work as well as an iterative and incremental approach, if at all. This doesn't mean you shouldn't be spending any time modeling, it means any up-front models created should be treated as informal at best. Perhaps it makes more sense to not even call them models because that suggests a level of formality we want to stay away from initially. Simple diagrams treated as sketches are a good practice to follow early on.

Formal models of software systems created after the system in question has been deployed in a real environment can prove valuable. The reason for this being that you have a functional system that is relatively stable. This is because after a system has been deployed for a while, hundreds if not thousands, of smaller bugs have been eliminated. These are the types of bugs that a software model isn't likely to solve in a timely manor. With the smaller issues mostly removed, we are free to tackle larger design issues that aren't easily solved with code.

One of the first things you might want to model are the dependencies between the packages and modules that make up the system. I've tried this before and was amazed at the problems I was able to see before even trying to model inheritance between classes. When you have several dependency lines crossing one another, it just looks bad. This is often a reflection of a sub-optimal design. The poorly painted picture provides quite the motivation to fix these issues. The same goes for class hierarchies. The relationships among the elements in the system, not just inheritance, are worth modeling. The value of modeling the details of each element isn't as high. Encapsulation also applies to software models to a certain degree.

The Face Of Bad Code

Lets face it, we've all written bad code at one point or another. If we hadn't, we probably would never release any functional software. Remember, code that isn't ideal doesn't equate to code that doesn't run and help someone else accomplish some task. Code can always be re-factored, and, it should be re-factored.

I often find myself testing my own software from and end user perspective and thinking about the code that is running when I perform certain actions. I think "well, it works, but just barely". I have to force myself to think "well, it works, and that is all the user cares about; it can be re-factored later".

Don't be tempted to re-factor before you get something functional into the hands of the end users. Make notes on what doesn't work well and fix it in conjunction with the user-provided feedback. If you don't release, you don't get the feedback. Only you as the developer know what needs to be re-factored, only the end user knows how well your software solves their problem.

Software Artifacts

What exactly are software artifacts? Put simply, a software artifact is a file that exists as part of some software system. The most common software artifacts are source code files and executable files. What isn't usually considered an artifact, however, is the logical design of the system.

It sounds strange that the system design isn't considered a software artifact but in most cases, it is the truth. The design of any software system is implicitly captured in the source code files. Because without the system design, there wouldn't be any source code files because they would have no reason to exist.

If the software system is modeled with UML, shouldn't the model files themselves be considered software artifacts. I would like to think so. Especially since they do a better job of making the system design explicit than the source code does.

Additionally, UML models can also make the software artifacts of the modeled system explicit. That is, you can have meta-artifacts. This of course assumes that the model itself is considered an artifact. If it sounds too confusing, it really doesn't have to be. UML artifact elements can help illuminate where in the model these artifacts, usually source code files, are expressed as a logical design.

Perfect Software

Is there such a thing as perfect software? Probably not. At least not according to this entry. Here, we see that there are varying degrees of bugs. Some bugs minor enough in nature to do no harm to the user. These are often considered minor annoyances, not show-stoppers. There are show-stopping bugs though, and these are the ones you simply cannot release with.

So how much does the description of what the software does influence what is considered a bug? There are obviously many limitations that cannot be overcome with most software. But what if these limitations, and "gotchas" where better documented along with the software? Would that lessen the gap between what the software does as expected and what is actually expected by the user?

Cannot Reproduce

So what exactly is the course of action when a development team cannot reproduce a bug that has been reported? Do they simply tell the customer they are out to lunch and that everything is working fine? Well you obviously can't tell them that if you expect to keep them on as customers. That would be like a doctor telling you that you're fine because nothing showed up in his tests. You know your not fine.

And that is how the customer feels when they encounter bugs. They don't need to hear that your tests cannot replicate the same problems they are having. Their pain is real. Even if your unit tests are telling the team everything is in perfect working order doesn't make it so. A customer coming to you with problems can mean any number of things. Your unit tests could themselves be buggy. Or they could just simply be missing something. Humans create software and so the software is prone to human error.

Customers are also humans and just letting them know that you are genuinely concerned about their experience with your software will get you a long way. Even if it takes a while to track it down, the problem does exist. So step-by-step, work it out while keeping the customer posted. And if there isn't a bug in the software, the user is still complaining about something. Otherwise, you would have a perfect product. I've never seen such a thing, so there is always something to aim for.

Two Plus Two Check

Just read a fantastic article on why the Toyota engineers can't claim that their software isn't bug free. They just haven't tested enough if they aren't finding bugs.

The fact that two plus two isn't always going to be four within running software systems shouldn't come as any great surprise. There are too many external variables that are out of the software's hands.

Fear Of Modeling

Does the idea that there is a general fear of modeling software sound like a real problem? Or, is it simply a matter of practicality? In most circumstances, modeling software, either during implementation or before, isn't beneficial to the project. Practicality aside, there are many large software projects in existence today haven't had requirement of any formal modeling in order to succeed. This doesn't mean that these development teams responsible for these projects have a fear of modeling. It means that they were able to approach the problem at hand tackle in a timely, and predictable manor.

So what does cause a fear of modeling? There are far too many reasons that organizations as well as individual developers don't model the software they are building to give here. There are, however, some very generic reasons that most software goes without a model. The chief reason being a generalized fear of modeling. Not just the act of modeling itself, which is often a very enjoyable experience. This fear of modeling arises due to a number of inter-connected factors.

The technology exists today to model just about anything, including software. Impossibility has nothing to with the problem. Further, there are many professional developers who have at least a fundamental grasp of modeling standards. These models, using standardized notation or not, can be illustrated using old, legacy technology, pen and paper. Shocking.

If the project is slightly more important than something you might contribute to on the side, such as an open source project, it is probably a better idea to construct any software models with software. It is easier to communicate with others using these models. Particularly, it is very helpful to provide a repository that stores all models for a given project. Nothing is lost, neither good nor bad. We can still learn from bad models.

Getting back to the fear that is involved whenever modeling software in various development cultures. Is the fear of modeling restricted to those team members intricately entwined with the code? Absolutely not. Any activities that are executed by a team affect every team member. In other words, modeling software that is about to be implemented requires both time and effort. And and here is the mythical part, the produced models aren't usable by paying customers and aren't worth doing. In some cases, the argument that software models aren't worth doing do to timing and resource constraints holds some merit. Consider an getting a patch out to an already deployed system. In this scenario, getting the design right is hardly more important than keeping the customer.

Is it possible to convince managers that modeling the software you, as a team are building has value? Of course it is. What really helps here is being able to produce high-level, non-technical, big-picture models of the system in question. If managers feel that they can better understand what is being built, they can better relate to why other modeling activities help developers better understand the system. And that means your boss is more likely to view software models as a valid product artifact.

Developers are obviously the main beneficiary of software models. The purpose of a software model is to better understand a software system. That is it. There are endless ways in which a developer can better understand a system but when they do, it results in a better product. Developer's fear of modeling often stems from an emphasis on producing a large, complete, and correct model before implementation has begun. It is true that you should start modeling before you start coding but don't get carried away. You'll often get a sense of when it is time to test out an idea, in code, while modeling. Don't resist the urge to code while modeling and don't abandon the model once coding has started.

What should software development teams be using to model software with? The UML offers a coherent set of standardized software modeling constructs. The UML in and of itself can be a source for fear of software modeling. A common misconception of the UML is that the entire set of modeling elements should be used for any given project. This couldn't be further from the truth. Use only what you need. The other elements are there if, and only if, you need them. I would recommend that each development team member have a basic understanding of commonly used UML elements. Everyone can jot down ideas, pass them around, using a standardized notation. More advanced users can then merge ideas into more formal models if, and only if, they are needed.

Modeling is not importing a set of classes that have already been written as specific programming language instructions into some modeling software in order to produce a class diagram. While this can provide some useful insight into older systems that have already been implemented, doing this with newer systems misses the mechanical act of constructing a conceptual illustration. Modeling can have some hidden, subtle benefits.

Software modeling can be be hugely beneficial more many reasons. Although there is the illusion of lost productivity due to building models, these fears can be put to rest by putting software models to work. They aren't going to jump up and prove their own worth.

Software Maintenance

This entry talks about some of the problems faced by current software maintenance practices. It highlights some of the various maintenance methods used to maintain deployed software. Of course, not many seem to do it right.

Problems arise mainly because of incompatibility between software versions. Typically, the entire software package has a version assigned to it. This includes all the constituent parts of the application such as modules and data structures. What if this individual components were giving a version instead of the whole? Well, there are systems out there in existence that do just that according to the entry.

What about taking this atomic version schema idea to the URIs of RESTful APIs. Indeed, this idea isn't anything new as many APIs support this feature. The main problem faced by web applications when performing server-side upgrades is the cached clients. Javascript that interacts with the URIs on the client's behalf may be stuck using an old API version. This is fine if the API version number is part of the URI. But backward compatibility can only be maintained so far back. This can be dealt with much easier if the expected version is part of the URI. If an unexpected version is requested, a message can be displayed to the client telling them to download a newer client. Alternatively, the new client code could be transparently delivered to the client as a response to using an incorrect version number.

Evaluating Development Processes

I read an interesting entry here about the software development process and it gave me a reminder of how simple, in fact, it can be. I was reminded of some of the common aspects of the software development life cycle and that they are all important for success, to varying degrees. The key thing is that variability.

Analysis, design, implementation, and testing seems to be the common factor in any aspect of the development process. Realistically, one can't create software without crossing each of these phases at least once. They all must occur, ideally longer than just briefly. But whatever the development process that is chosen by a given team, each of these phases is going to need evaluation in terms of time investment.

This is the part that comes even before a given project comes into existence for a software development team. This is where it is important to set a consistent time to be spent for each phase. But this isn't going to happen for the first project that is hammered out by a team. Trying to set an appropriate amount of time for each development phase is completely pointless. The first project is going to be trial and error. What is important is that once the team is able to find some time allotment that works, stay consistent. Consistency makes all stakeholders involved happy when it comes to timing. This includes the customers.

Palm And Open Source

An interesting read over at IT wire about how Palm is apparently turning down applications built to run on its' platform from appearing in its' application catalog. There is nothing inherently wrong with this as they have a right to do so. The strange thing is that the rejected applications included an open source license.

If nothing else, this shows that there is still a bias against the fact that open source applications are not unique to specific vendors. That is, users can go out and get these applications, even modify and rebuild them, all on there own. Why this scares companies so much baffles me to no end. Especially given the huge momentum the open source movement has been gaining over the past few years.

Developer Progress

Eric Spiegel has posted an entry over at IT management on why developers are let go. I figured I'd chime in and say that most of what he claims isn't entirely true.

You do not need to promote your code by bragging about it or by any other means. Does the code do what it is supposed to do? Great. Move on. The theme of course being to simply get stuff done. That is what developer progress is. Just continuously make progress whether that is fixing bugs or implementing a new feature. Time wasted bragging about stuff does no one any good.

Documenting everything you do is also a very good idea. But do it in a format that is a useful project artifact as opposed to promotional garbage. Just because you document stuff that you have done in a way that way that is meaningful to others doesn't mean you can't use that same documentation to defend yourself should the need arise. It probably wont if you continue to make progress.

Finally, if your not making progress by simply getting things done, you are not motivated. If you are motivated, you get things done and make progress. If a developer isn't motivated and is still able to get stuff done, who cares.

Breaking Release Cycles

There exist today endless software methodologies, each of which, allow for differing policies on producing releases. Some methodologies allow for variable length between releases while some dictate a strict cycle length. The methodologies that follow a strict release time-line are most likely using an agile approach to software development. When using this approach, the release dates for the software are one of the, if not the most, important rules to stick to.

When using an agile approach to software development, there should be a fixed amount of time between releases. This may at first seem counter intuitive. How can a development methodology be agile if the time-line is of fixed length? Agile should support change and that is indeed one of the key benefits to using an agile approach. However, not everything can change. There has to be at least some formal rules that allow for some sort of organization. If there is nothing strict in place, the practice is flawed because nothing would ever get released. And it is the continuous releasing of software that provides the invaluable feedback that plays a huge role in the agile methodology. Take a look at some open source projects that have a six month release cycle. Sure, there is feedback from the user community, but they don't see how their feedback is reflected, which, in turn, generates more feedback and so on.

With a shorter release cycle, this feedback is reflected sooner. But what about when the agile approach is used for developing a solution for a paying customer. Does their request for some change or some feature mean that the release cycle length should be changed? In almost every case, I would say no it doesn't. They are paying you to develop software because you know how to do it and constantly pushing back release dates does not help anyone. The only exception to this rule is when it is a deal breaker. If holding up the release will prevent the loss of money, you simply do not have a choice. Otherwise, there is always a good reason one can give for not including a requested feature. This is especially easy to explain to customers when you always ship predictably and on time.

Software Preservation

Grady Booch, over at the handbook of software architecture makes a good point of why preserving classic software systems for future generations is important. There is a storyline behind every system. Within this story lies an endless supply of rationale behind tricky technological problems. Of course, the rationale behind doing such and such with some software component would probably be worth something to some developer in the future. The how probably isn't as important, although it might be. Everything should be preserved as best as possible.

It might be difficult to say what might happen if the software of today isn't preserved for future generations. But what harm could be done if every meaningful software system were preserved for the future? There is probably a mountain of historical data that exists today that is of no particular use besides self-interest. At least it has no use yet. The only thing that is certain is that we'll never know if it proved to be worth-while if we don't do it today.

This got me thinking about software that isn't that old. Maybe a few years old. What if I as a developer worked on it but it was no longer of particular use to anyone else, would it be worth preserving? I think so. I've had countless times where I just thought of something I did to solve a similar problem in a older project. Trac really helps here. I just launched Trac and sure enough, I was able to find what I needed.

The Undesigned

In an interesting entry over at agile focus, we are given an idea of what the myth of the undesigned is all about. Well, in this context, it is all about undesigned software, of course. What this entry stresses is the fact that the act of software development is nothing but design and I would have to agree here. The main argument is that the philosophy of adding design to already-built software is fundamentally flawed. I would also agree here. This does however raise several questions as to what counts as already designed software (if you don't subscribe to the notion that all software is designed). For instance, in the context of implementation design, the actual code itself, it is very hard to add design to.

This, I think is what the author is stressing. An example of adding design to code might be cleaning up code that was previously sloppy. But is this really design that is being added to the code or simple rearrangement? I suppose some constraints must be imposed on this sort of cleaning up. This would simply be to ensure that code design doesn't take place while "cleaning up".

Not designed is indeed a bad design but designing nothing but code is also a bad design. Implementation is one thing but it is always best to keep the important, platform-independent, design out of the code and in a model of some form or another.

Software, Patents, and Innovation

An interesting entry over at the open source initiative asks if patents hinder or encourage innovation. This is an interesting question regardless of the field in question. The entry talks about the centuries-old case of the steam engine. Once a patent for an idea has been established, anyone wishing to employ this idea will be in debt to the patent holder. How likely is anyone wishing to use or further develop the idea to get involved? Also, how does the patent holder benefit from this situation? They don't. In fact, the encouragement often works in the opposite direction. In many cases, there is no alternative than to use an idea that has been patented. This restriction then grows to resentment toward the patent holder and that is not something any designer, especially in the software industry wants. The idea of openness and community collaboration not withstanding, software suffers the same patent-type problems.

Early on in the development of the steam engine, the idea was patented. This brought about an era of the steam engine where there was no spectacular innovation. Years later, the steam engine designers lifted the patent. Sure enough, this brought about an era of design innovation. Such much so that the innovation rate of the steam engine doubled over the previous patented era. Designers and engineers are not turned away by the thought of patent infringements.

It seems that patents in general do not benefit anyone. The main motivation patented ideas offer is to create the patent in the first place. This is an extremely flawed approach to building anything well. The concept of "do something you love" is tossed out the window. Who loves to patent things? Why not do something well and have the rest follow. In the end it all comes down to the designer's attitude. In the case of the steam engine, once the patent was lifted, attitudes changed. That, in turn, changed everything.

In software, patents are hard to define. There is simply no way around it. Especially trying to patent an algorithm of some sort. If I were to take an existing algorithm that has been patented, completely re-factor it, and end up with the same result, would that be considered patent infringement? If so, what is really being patented is a specific output paired with a specific input. That would be very unjust.

When inception exceeds elaboration

The inception phase of any software development life cycle is supposed to be the first phase. Even if you are hacking away on something you dreamed of the night before. You still woke up, and thought "I'm going to try this out. Even if it doesn't work, at least I'll know". And that was the inception. You thought of something cool and made the decision to code it.

Even in these trivial cases, there is still a very brief inception phase. Which is how it should be. Well, maybe a little longer than five minutes. But you should never be thinking "Oh wow. This idea is so great. This is going to revolutionize the way people use computers." for too long without actually building anything. Design something right away at the very least. Even jotting down some simple notes is often enough to let yourself or a team member know if you are completely out to lunch.

If you hold on to ideas for too long, you also run the risk of skipping elaboration entirely. Again, this applies to all software development. Even if you are hacking away, at least you started hacking right away. It is an infinitely bad idea to have this great idea for a very long time and assume that thinking about it, or even talking with team members about it, is the elaboration. Because it isn't. Thinking so spells nothing but failure.

Open source breeds new ideas

When people here open source they often think of free software. Companies associate open source with cost savings. This makes sense since the goal of any software is to satisfy the needs of who is using it. With proprietary software, this is all there is. The perspective of the end user is all that is allowed. Sure, there are usability and missing feature requests that can be made. But that is all. There is no looking under the hood.

The big selling point with open source software aside from the cost savings is the availability of the code. In most cases, this code can be modified and redistributed. Many open source projects have built communities of users and developers. With the source code at your fingertips, it is much healthier for the project in terms of diagnosing bugs. There are "more eyes on the code". Imagine you have chest pains and you go to see your doctor. He tells you your free trial has expired and in order for him to use the appropriate medical equipment, you need to purchase a license.

There is another major benefit to making the source code of a project available. And that is new ideas. Aside from the specific problem the software was designed to solve, the source code can serve as a repository of implementation solutions. Developers can see these solutions and adapt them to their own needs. If you create an open source project, odds are you will use or extend existing ideas from other open source projects. Likewise, if your project matures to a stable software package, no doubt others will use your ideas. It is a very productive cycle.