The following guide is a very helpful resource. I recommend that you read it and determine the branching strategy that you want to use before you setup your team projects.
The following guide is a very helpful resource. I recommend that you read it and determine the branching strategy that you want to use before you setup your team projects.
Posted on 06/27/2011 at 12:43 PM in Microsoft .NET, Software Development, Software Engineering Process, Tools | Permalink | Comments (0)
Reblog (0) | | Digg This | Save to del.icio.us |
Effectively reusability doesn't just happen. It is a planned event that takes time and resources. A separate domain engineering and knowledge base is required to promote and push its use throughout the organization.
The problem with reusability is that it usually isn't cost effective until a component has been reused (with very little analysis or modification) 5 or 6 times. Designing components for reusability slows down the current design and implementation process and requires a domain engineering/knowledge sharing organization to support and carry-on the reuse efforts.
Reuse is most effective when it is tied to business or technical patterns. The lower the level that reuse occurs the smaller its payback. This is because the first four (4) levels that I listed above only affect the implementation or coding cycle. Architectural and business patterns and customized packaged applications cut across many more of the software development lifecycle (SDLC) cycles and therefore have a larger impact.
Posted on 02/23/2011 at 10:54 PM in Software Architecture, Software Development, Software Engineering Process | Permalink | Comments (0)
Reblog (0) | | Digg This | Save to del.icio.us |
I agree with the premise of this ComputerWorld article by Frank Hayes - "propose big and build small".
Just make sure that you don't follow a huge waterfall methodology. This approach requires an agile methodology.
As you implement additional portions of the system you will have to revisit and refactor portions that you already finished. Don't stress out over this.
Change and release management are also important parts of making this approach work.
Posted on 12/20/2010 at 10:40 PM in Software Development, Software Engineering Process | Permalink | Comments (0)
Reblog (0) | | Digg This | Save to del.icio.us |
[Note: Originally posted on "improving outcomes blog" on 2Mar2010.]
Simple is hard.
It is much easier to do things the complex way. It takes very little thought about what you are doing or how you are doing it if you don't care about the complexity of the process or the resulting product.
As Abraham Lincoln said, “I'm sorry I wrote such a long letter. I did not have the time to write a short one.”
Mark Twain is also quoted as saying, "I didn't have time to write a short letter, so I wrote a long one instead." [update 8/23/10]
So, if complex is easier and faster, and simple is harder and takes longer - why do I want to simplify?
As I have discussed in previous posts - it comes down to the difference between ad-hoc and repeated-use processes and products. The difference between designing/optimizing and executing/maintaining.
If a process is performed just once or if there is only a single implementation of a product then there is little benefit to simplicity. These are truly ad-hoc processes and products.
For everything else, the answer is quality. Quality attributes like functionality, reliability, availability, usability, efficiency, maintainability, and extensibility.
It is hard to get the results you want on a reliable and repeatable basis using complex processes and products. Complex processes and products have more failure points and break down more often than simple ones. And, when they break down it is difficult to find the root cause of the error and fix them. It is also very hard to learn complex processes and products and become efficient using them. Finally, complex processes and products are difficult to modify or extend to support changing needs.
Where does complexity come from? It can creep into your processes and products in many ways. A few ways are:
Converting ad-hoc processes to organizational processes.
Designing without the real end-user in mind.
Layering governance processes onto organizational processes. This is also know as the bureaucracy factor.
Poor implementation, including training, of organization processes.
Two key approaches to remove complexity are:
Design all processes and products with the focus on the end-user. Understand the needs of the end-user and meet those needs as simply as possible.
Only add tasks, features, and functionality to your process and products that are absolutely required. Also, remove any that are no longer required. Leaving unnecessary bloat in your processes and products are a big cause of complexity.
References:
Harvard Business Publishing Webcast - Take Complexity Out of Your Company, with Ron Ashkenas, author or Simply Effective.
Posted on 08/31/2010 at 10:05 AM in Business Process, Enterprise Architecture (EA), Software Architecture, Software Engineering Process | Permalink | Comments (0)
Reblog (0) | | Digg This | Save to del.icio.us |
[Note: Originally posted to "improving outcomes blog" on 22Feb2010.]
"Life is a journey, not a destination." - Ralph Waldo Emerson.
A destination is (Collins English Dictionary):
- the predetermined end of a journey or voyage
- the ultimate end or purpose for which something is created or a person is destined
Life is like a roller coaster. There is a beginning and an end - and they are both the same place. The goal of riding the roller coaster is not to get back where you started. It is to enjoy the wild ride in between.
Businesses also have a life line. They are formed and they are dissolved. Their goal is also not some predetermined or ultimate end. It is the value that they provide to the people they encounter along the way. Because, if a business reaches an ultimate end and then remains static it will soon cease to exist. As I stated in my "Dynamic versus Static" entry on 1/26/10, businesses must remain dynamic to continue to exist and provide value.
I don't think that many people consider the end of their life or the day they dissolve their business as their goal. However, many do forget that it is the journey and not the end result that provides the reason for existence. They rush through everything they do without really experiencing, enjoying, and learning - as if they are on a race to the end.
The same also applies to activities and milestones along the way. A milestone is (The American Heritage Dictionary):
- A stone marker set up on a roadside to indicate distance in miles from a given point
- An important event, as in a person's career, the history of a nation, or the advancement of knowledge in a field; a turning point
Goals and milestones are important metrics to keep your journey on track and make sure you are headed in the right direction. It is still important to remember that it is everything you do and learn on the journey that is more important than the goal or milestone.
Take school for example. If your goal is getting a diploma as quickly and easily as possible then you are missing the real purpose of an education. The real purpose happens during the journey, the more you take advantage of all your opportunities to learn as much as possible, instead of the minimum, then the better prepared you will be when you complete your studies.
The same thing also applies to projects. If you approach each project as only a quick and easy end goal then each project will be new and exciting but will not provide lasting benefits beyond just getting it done.
I am not saying that quickly, efficiently, and cost effectively are not important attributes of a project. Or, that getting to "Done" is not important. I agree with all of the points of "The Cult of Done Manifesto". In fact, it is because I agree with them that I believe the journey is more important than a procrastinated or perfect done.
Process improvements and quality programs are based on the journey. They measure the end product; but, to realize improvements, changes must be made to the process followed during the journey.Posted on 08/31/2010 at 10:03 AM in Business Process, Quality, Software Engineering Process | Permalink | Comments (0)
Reblog (0) | | Digg This | Save to del.icio.us |
[Note: originally published on "improving outcomes blog" on 2Feb2010.]
Checklists are not a new concept. However, they have been generally under-appreciated for the benefits they can bring to complex tasks in a simple and unobtrusive manner.
In many situations people try to over-specify and over-control processes with lengthy policies and procedures that no one reads, remembers, or follows. It is not that these policies and procedures are bad, it is just that they need to be accompanied by simple checklists that ensure that the key policy goals are being met.
Here is a checklist that we used for our Change Control Process. It was used to ensure that you were prepared for the Change Control Board meeting. If you came to the meeting with this checklist completed then you would quickly get approval to move forward. Download Change Control Form.
I haven't personally read it yet but The Checklist Manifesto: How to Get Things Right by Atul Gawande (Dec 2009) revisits the power of the ordinary checklist. You can listen to the Harvard Business IdeaCast, Using Checklists to Prevent Failure (22 Jan 2010), which is an interview with the author. A commentary on the book can be found at The New York Times: Freakonomics Blog: The Checklist Manifesto.
The following research and information about checklists are also very useful:
Posted on 08/31/2010 at 09:50 AM in Business Process, Software Engineering Process, Tools | Permalink | Comments (0)
Reblog (0) | | Digg This | Save to del.icio.us |
The concept of the "golden" and immutable database schema makes me crazy.
Agile methodologies, like SCRUM, have been adopted by many development groups to account for the fact that a perfect and unchangeable requirements specification will never exist before programming begins.
However, a big impedance mismatch will threaten your efforts if the application's database schema is under the control of a separate DBA group that is following a traditional waterfall methodology. (Note that I am talking about the application's database schema and not enterprise data store schemas.)
Academically I have seen and discussed many different ways of dealing with the issues associated with database changes. Martin Fowler and Pramod Sadalage discuss many of these issues in "Evolutionary Database Design".
In practice I have favored individual developer database instances with data architecture/DBA review. Just as solution architects don't babysit each system design change I don't think that data architects or DBAs should either. Any issues related to a design change can be dealt with using regular reviews and subsequent re-factoring.
In this practice the database schema and build scripts are part of the solution. To get a local database instance to work with the developer just gets the latest solution from source control and runs the DB build script. If they need to make changes to the DB then these changes are made and tested locally by the developer and then finally checked into source control for the rest of the team. The developer who makes the DB changes is also responsible for making sure that any required code changes are also checked in at the same time. A communication mechanism needs to be put into place so that the rest of the team knows that they will need to update their database at their next integration point (i.e. source code get latest).
Depending upon the phase of development, changes may be made to the original schema and everyone will have to rebuild their database or changes will be implemented as alter scripts and everyone will only have to update their database. Once the system goes to production all modifications will need to be implemented as alter scripts.
Posted on 08/31/2010 at 08:46 AM in Software Architecture, Software Development, Software Engineering Process | Permalink | Comments (0)
Reblog (0) | | Digg This | Save to del.icio.us |
In UML version 1.4 there were 9 diagrams.
In UML 2.2 there are now 14 diagrams. There are seven structure diagrams and seven behavior diagrams. Within the behavior diagrams four of them are interaction diagrams.
But, this entry isn't really about the number and type of UML diagrams. It is about lean-modeling using UML. As I mentioned in my entry on Modeling Philosophies, over-modeling is worse than under-modeling. What you really want to achieve is just-what-is-needed-just-in-time modeling.
You have been asked to develop the software architecture for a new system and to document it for presentation and review. And, by the way, use UML diagrams. What do you do? Throw your hands up in exasperation and complain that you don't have enough time to do 100's of pages of documentation?
No.
To start with, let's assume that you were going to do some analysis and design before you started coding. The UML models should flow naturally from your analysis and design process.
You are going to need to determine what things/nouns/objects/entities you are going to be working with. Document them in a class diagram.
You are going to need to determine what actions the user or other systems can cause or trigger. Document them in a use case diagram. If the actions are not self-evident then provide more detail using activity diagrams.
If an action is complex and requires coordination between multiple objects then you may want to create a sequence diagram to illustrate the interaction between the objects.
If you have a process flow with a number of states and each state can transition to multiple other states then a state machine diagram is very useful.
I also recommend that you develop a package diagram for your system. It will help you determine how to structure your code/solution, group your objects together for deployment (dll / jar files), and avoid cyclical references.
Finally, I am not saying that you shouldn't use any of the other diagrams. Depending upon your application type, its complexity, and your audience, additional diagram types may also be very useful.
Posted on 08/20/2010 at 08:51 AM in Software Architecture, Software Engineering Process | Permalink | Comments (0)
Reblog (0) | | Digg This | Save to del.icio.us |
Are you having problems determining which phase you are in and what your focus should be?
Forget the standard names:
Use the following questions to determine if you are on track and to remind yourself what you are trying to achieve:
When you have answered yes to the question for that phase it is time to move to the next phase.
If you realize that you will not be able to answer yes to a phase, within your time and budget constraints, then it is time to kill the project.
No one likes to fail but not everything is possible and killing a project at $1mil is a lot better then doing it at $10mil or $100mil.
Posted on 08/19/2010 at 10:10 PM in Software Engineering Process | Permalink | Comments (0)
Reblog (0) | | Digg This | Save to del.icio.us |
"The deliberate march toward delivery is the hallmark of true iterative development." (author unknown)
To me it doesn't matter which software development life cycle or methodology you use. It is more important that you adopt agile principles in your execution.
Principles like those laid out in the "Manifesto for Agile Software Development" and "12 Principles of Agile Software".
I have worked as a Unified Process / Rational Unified Process consultant, mentor, and trainer for many years. In practice I always favored Scott Ambler's philosophy that documentation is for communication and to keep it to the minimum amount required for the project.
On smaller projects, under six developers, I found myself following more of a Scrum-like process and it worked out well.
Now that there is a good Scrum template(Visual Studio Scrum 1.0) for Microsoft Visual Studio and Team Foundation Server I have completed my Scrum conversion.
Posted on 08/16/2010 at 12:33 PM in Software Engineering Process | Permalink | Comments (0)
Reblog (0) | | Digg This | Save to del.icio.us |