Designing software is a continuous task, requiring enduring effort and attention.
I strongly believe that the Code is the design. All efforts leading to the delivered code is just preparations for creating the design that gets released.
During the lifetime of a software product better and less good decisions are made along the way. Some decisions are made consciously and others more accidentally. After reading and discussing Technical Debt with my colleagues lately, I have come to think that is other economical terms that also fits on design decisions like investing. Investments can pay off, not paying off and not loosing, and loosing. What you do is make a bet. The greater the investment, the more certain you should be that is the right thing to do.
Ward Cunningham coined the Technical debt phrase. Martin Fowler and Steve McConnell has elaborated on it. This post tries to tie the investing term into software design. I really hope that by using these terms it is possible to create a software design meta language that is better understood by non technical decision makers.
Yesterday's decisions
Bad design from the past create technical debt. This debt should be downpayed (not just paying interests). It has to be a prioritized objective in every project to resolve this into better solutions.
Now
Sometimes there is a need to do something to the design just get the next release out the door. These decisions typically creates debt as a rule of thumb. Make these investments as small as possible. Update: Got a useful comment from @javatotto, about that the effect of these kind of design decisions should be isolated, so as few dependencies to them are created from elsewhere. Great comment that could be topic for the next post ;-)
Tomorrow
Investing for tomorrow is speculating. This is up front design, and often considered bad. This is especially true for projects that need the be able to change direction fast. It also requires an effort not helping you get the next release out of the door. You might even invest in something you will not need, which will represent a complete loss.
Small investments seldom make big trouble and can not represent big losses.
Big investments for tomorrow needs to be watched closely as they can potentially ruin the project. Maybe the worst thing about big investments are that they are extremely hard to dispose when they prove to be a loss. There is a cognitive attachment (ownership) that hinders replacing them with better solutions. The processes around big investments should be open, so that all people having a interests in it can have influence on how it develops. As I am a eager proponent for Open Innovation, I think especially these kind of investments can profit from developed as open source or at least open as possible.
Not paying down on the existing debt will ultimately be the terminator for a project. Final. I have seen some correlation between big investments and not paying down the technical debt in most projects I have participated.
Big investments for the future has potential to steal energy and focus (the projects short term capital) from things that should be fixed. Often it is the most talented developers involved in both activities, and they seldom manage to to both simultaneously. The worst case is when doing the wrong investment. That makes this even worse, as the debt grows dangerously fast.
Showing posts with label design. Show all posts
Showing posts with label design. Show all posts
Wednesday, March 25, 2009
Sunday, February 8, 2009
Let Open Source set you free and be unique
A bit of a bold heading, you would say? Well that may depend on your attitude against and knowledge about Open Source. My opinion is that when you master a set of open source products, they will let you develop more freely. This is probably not that different from proprietary products, but with Open Source you can get deep knowledge very fast. Chances are that there are many developers "out there" having expert knowledge about most widely used Open Source products.
This post focuses on these advantages of Open Source:
Inhouse competence
By hiring or employing the adequate Open Source competence software companies can get a head start on a project. The good thing about this is that the competence is not on the other side a phone or just being an email address. When challenges are met or there is a problem in production, the competence is right there with you.
Software standards
There is a lack of defined standards on how software should be designed. By design I mean what this article by Jack W. Reeves says. I do not doubt the value of visual software design, but this is just a vehicle for making the correct code design.
A lot of Open Source products has made such a strong foothold in software development that they more or less dominate in some categories of applications, e.g. the Spring Framework . Spring framework is very flexible, but by following the recommended conventions you will probably run into less trouble (not that impedes more trouble than other frameworks). That said, Spring is not very intrusive, so it should be pretty simple to adjust to conventions that is often also common sense.
When you adhere to the common sense conventions it mostly makes the software produced easier to use with other components and frameworks. It is necessary though to have the necessary competence when decisions is made along the way, just as you would with proprietary products. The difference, again, is that you do not have to get it from the vendors support or experts.
No procurement process
There is no costs, or at least they are very low, so getting permission to use Open Source is not an issue to discuss with the financial department. It is necessary to evaluate different products, also proprietary when they exists, for the project. Until now commercial products has often won these evaluations, but mainstream development is taking a new direction. I am not surprised that is happening right now, as the financial crisis raises questions about costly software.
An important consequence pointed out in the Agile Executive post, is that the software lives before the eyes of the user because with Open Source you can move as freely as the available competence is able to produce new features. This is very attractive, as the users keep coming back for exploring new functionality.
Another important point here is that when new technology surfaces, there is easier to switch when there has not been investments in commercial products. Software with a good design is flexible and makes as few assumptions of it's surroundings as possible.
Be free and unique
Now to the point of this post! Open Source let you, with the right competence, focus on the things you are good at, and deliver faster than with proprietary products. The business value or end user experience is what counts. Users mostly does not care how software is designed, but they value good software.
When you can focus on this, chances are that the product will be better and the users more happy. Unhappy users can express them self freely and quickly on the internet, especially after the advent of Web 2.0. A product must often rely on the word of mouth. With Twitter and the like being adopted at a blazing speed, word of mouth is spreading very fast.
Examples that this is true is flourishing:
This post focuses on these advantages of Open Source:
- Competence can be inhouse and not just on a support line
- Defines what is more or less standards of how software us built today
- No up front costs and procurement process
Inhouse competence
By hiring or employing the adequate Open Source competence software companies can get a head start on a project. The good thing about this is that the competence is not on the other side a phone or just being an email address. When challenges are met or there is a problem in production, the competence is right there with you.
Software standards
There is a lack of defined standards on how software should be designed. By design I mean what this article by Jack W. Reeves says. I do not doubt the value of visual software design, but this is just a vehicle for making the correct code design.
A lot of Open Source products has made such a strong foothold in software development that they more or less dominate in some categories of applications, e.g. the Spring Framework . Spring framework is very flexible, but by following the recommended conventions you will probably run into less trouble (not that impedes more trouble than other frameworks). That said, Spring is not very intrusive, so it should be pretty simple to adjust to conventions that is often also common sense.
When you adhere to the common sense conventions it mostly makes the software produced easier to use with other components and frameworks. It is necessary though to have the necessary competence when decisions is made along the way, just as you would with proprietary products. The difference, again, is that you do not have to get it from the vendors support or experts.
No procurement process
There is no costs, or at least they are very low, so getting permission to use Open Source is not an issue to discuss with the financial department. It is necessary to evaluate different products, also proprietary when they exists, for the project. Until now commercial products has often won these evaluations, but mainstream development is taking a new direction. I am not surprised that is happening right now, as the financial crisis raises questions about costly software.
An important consequence pointed out in the Agile Executive post, is that the software lives before the eyes of the user because with Open Source you can move as freely as the available competence is able to produce new features. This is very attractive, as the users keep coming back for exploring new functionality.
Another important point here is that when new technology surfaces, there is easier to switch when there has not been investments in commercial products. Software with a good design is flexible and makes as few assumptions of it's surroundings as possible.
Be free and unique
Now to the point of this post! Open Source let you, with the right competence, focus on the things you are good at, and deliver faster than with proprietary products. The business value or end user experience is what counts. Users mostly does not care how software is designed, but they value good software.
When you can focus on this, chances are that the product will be better and the users more happy. Unhappy users can express them self freely and quickly on the internet, especially after the advent of Web 2.0. A product must often rely on the word of mouth. With Twitter and the like being adopted at a blazing speed, word of mouth is spreading very fast.
Examples that this is true is flourishing:
- Android
- Google Chrome, the browser no one expected and got Google a lot of positive attention
Subscribe to:
Posts (Atom)