Design patterns are a great tool for software developers. The classic text by the "Gang of Four", Design Patterns is a great starting resource. I honestly will have to admit that I don't have all of the patterns memorized, but I do refer to them on a regular basis. Whenever I find myself struggling with a design decision, I flip open the book try to get some inspiration. I don't always find a magic answer, but it can help me straighten out my thoughts.
Design patterns are great, but not anything new or earth shattering. I believe that most good software engineers tend to use the generally ideas anyways. They may not match exactly what is described in the traditional design patterns, but generally they are similar ideas. The introduction of formal design patterns just helped to formalize and standardize these good design principals.
In my opinion, design patterns are not the answer to all things. They provide a framework and common vocabulary for organizing my thoughts, and having discussions with other developers. Since the original book came out others have come up with additional patterns, which in most cases provide similar value. I recommend to all software developers to make sure that they are familiar with design patterns, and have a resource available to use when they need it.
Showing posts with label software design. Show all posts
Showing posts with label software design. Show all posts
December 2, 2010
October 28, 2010
The Pragmatic Programmer
After reading Code Complete, I decided to continue with another book that had been on my reading list for a while. The Pragmatic Programmer
is another excellent resource for developers. When comparing these two books, I would say that Code Complete is probably a better starting point, since it seems to cover more topics, and provide more details. With that said, Pragmatic Programmer is still a worthwhile read. There is definitely overlap between the two books, but there are some items that Pragmatic Programmer covers, that I didn't remember reading in Code Complete.
The book seems to be more humorous than some of the other software books I've read, which makes for easier, more enjoyable reading. The information in this book is what really helps separate the programmers from the software engineers. These concepts are what help make developers more valuable employees, and more productive engineers.
If you haven't ready Code Complete, I would recommend it first, but with that said I still think Pragmatic Programmer is a worthwhile read.
is another excellent resource for developers. When comparing these two books, I would say that Code Complete is probably a better starting point, since it seems to cover more topics, and provide more details. With that said, Pragmatic Programmer is still a worthwhile read. There is definitely overlap between the two books, but there are some items that Pragmatic Programmer covers, that I didn't remember reading in Code Complete.The book seems to be more humorous than some of the other software books I've read, which makes for easier, more enjoyable reading. The information in this book is what really helps separate the programmers from the software engineers. These concepts are what help make developers more valuable employees, and more productive engineers.
If you haven't ready Code Complete, I would recommend it first, but with that said I still think Pragmatic Programmer is a worthwhile read.
October 25, 2010
Software Engineering Handbook - Code Complete
I recently finished reading Steve McConnell's software development manual: Code Complete
. It is a hefty read, but well worth it. As I was reading I found myself quickly skimming over some sections that I felt comfortable with, while at the same time other sections really made me think about some of the ways that I approach software development. I also found that some of the topics that I read were things that I tend to do naturally, but it was still nice to see formal definition and documentation to support what I do. The book covers all of the major areas that I would expect an experienced developer to be comfortable with.
Many of the topics are only briefly covered, but it is still an excellent source for how to develop software. For some programmers this may be their first exposure to these topics, so it is a great way to expand your knowledge. Some of these brief introductions should trigger further investigation and research for topics that are of interest. Even if the topics aren't' all covered in depth, it is nice to just know what ideas, practices, and techniques are out there.
In the end, I would say that Code Complete a "must read" for all software engineers, especially for those with at least 2-3 years of experience under their belt. It's still useful for the novice software developer, but the quantity of information may be a little overwhelming for beginners.
. It is a hefty read, but well worth it. As I was reading I found myself quickly skimming over some sections that I felt comfortable with, while at the same time other sections really made me think about some of the ways that I approach software development. I also found that some of the topics that I read were things that I tend to do naturally, but it was still nice to see formal definition and documentation to support what I do. The book covers all of the major areas that I would expect an experienced developer to be comfortable with. Many of the topics are only briefly covered, but it is still an excellent source for how to develop software. For some programmers this may be their first exposure to these topics, so it is a great way to expand your knowledge. Some of these brief introductions should trigger further investigation and research for topics that are of interest. Even if the topics aren't' all covered in depth, it is nice to just know what ideas, practices, and techniques are out there.
In the end, I would say that Code Complete a "must read" for all software engineers, especially for those with at least 2-3 years of experience under their belt. It's still useful for the novice software developer, but the quantity of information may be a little overwhelming for beginners.
November 11, 2009
Business Requirements vs. Software Design
In the world of software development there seems to be two things that are always causing conflict. As a software developer I always want to do software projects "right." Most of the time this can mean significant time invested in infrastructure, design, architecture, and/or new code. As an executive I realize the value of getting things done as quickly as possible, but still with the right feature set.Both of these approaches can be valuable, and when balanced properly can lead to extremely valuable software.
On the software development side it always seems like it would be nice to have unlimited resources and unlimited time. If this were the case it seems like we could always come up with well designed, modular, maintainable software, that fills all of the needs of our customer. There would be time to do research, try out new technologies, and all of the other "cool" stuff that software developers like to do. Old code could be refactored to fit new requirements, new code would be well designed, fully unit tested and flexible enough to fit future needs.
On the business side all of these things are valuable, but there are many other things that come into play, like time to market opportunity costs, etc. Many times, the quicker you can get a product to market, the sooner you can see the response of customers and adjust/adapt accordingly. Taking another 4-6 months to get a product out may mean that a competitor is that much further ahead of you.
When these two ideas come together with the right mix, great things can happen. If developers are given enough time and resources to do a good job, then the software will have many of the same qualities as if the team had unlimited time. Of course the terms "enough time and resources" and "good job" are up for interpretation, and vary per project, but most teams should roughly know how much time they should spend for things to be good enough. Not perfect, just good enough. This means that people on the business side need to be understanding, yet apply appropriate pressure to make sure things are progressing.
When this all comes together teams can create great products. They won't be perfect, and they won't be quick, but they will fit the business need as well as possible and still not be just a jumbled mess of unmaintainable code. It can be hard to find the right balance, but it's worth striving for because it makes everyone happy: your customers, software developers and the people in charge. And you might even make a little money along the way.
On the software development side it always seems like it would be nice to have unlimited resources and unlimited time. If this were the case it seems like we could always come up with well designed, modular, maintainable software, that fills all of the needs of our customer. There would be time to do research, try out new technologies, and all of the other "cool" stuff that software developers like to do. Old code could be refactored to fit new requirements, new code would be well designed, fully unit tested and flexible enough to fit future needs.
On the business side all of these things are valuable, but there are many other things that come into play, like time to market opportunity costs, etc. Many times, the quicker you can get a product to market, the sooner you can see the response of customers and adjust/adapt accordingly. Taking another 4-6 months to get a product out may mean that a competitor is that much further ahead of you.
When these two ideas come together with the right mix, great things can happen. If developers are given enough time and resources to do a good job, then the software will have many of the same qualities as if the team had unlimited time. Of course the terms "enough time and resources" and "good job" are up for interpretation, and vary per project, but most teams should roughly know how much time they should spend for things to be good enough. Not perfect, just good enough. This means that people on the business side need to be understanding, yet apply appropriate pressure to make sure things are progressing.
When this all comes together teams can create great products. They won't be perfect, and they won't be quick, but they will fit the business need as well as possible and still not be just a jumbled mess of unmaintainable code. It can be hard to find the right balance, but it's worth striving for because it makes everyone happy: your customers, software developers and the people in charge. And you might even make a little money along the way.
October 3, 2009
Agile Software Development
There are many different software development methodologies that are practiced today. One of the popular choices today is Agile Software Development
. When I do software development I generally use agile techniques, but I wouldn't consider myself an agile purist. Where I work, we use scrum meetings, and very quick development cycles, and a few other agile ideas. But we don't use every agile technique.
I assume most people and businesses do this, but I try to be familiar with many different methodologies and practices as possible. I try to use the ideas and techniques that best fit the situation at hand. If I'm doing a large scale project, I try to do more work gathering requirements upfront, but if the project is much smaller I may just sit down with the project owner for a quick discussion and start designing and implementing from that.
I know some people are much more religious about this, and the idea of mixing and matching between different methodologies would be heresy, but it really does work. There are times that it is good to be strict and keep with consistent policies and procedures, but there seem to be many more occasions where flexibility is king. Within certain constraints and with a good understanding of software development, it can be very advantageous to be flexible. In days with tight schedules, limited resources, and never ending requirements we must do what we can to thrive and create great software.
. When I do software development I generally use agile techniques, but I wouldn't consider myself an agile purist. Where I work, we use scrum meetings, and very quick development cycles, and a few other agile ideas. But we don't use every agile technique.I assume most people and businesses do this, but I try to be familiar with many different methodologies and practices as possible. I try to use the ideas and techniques that best fit the situation at hand. If I'm doing a large scale project, I try to do more work gathering requirements upfront, but if the project is much smaller I may just sit down with the project owner for a quick discussion and start designing and implementing from that.
I know some people are much more religious about this, and the idea of mixing and matching between different methodologies would be heresy, but it really does work. There are times that it is good to be strict and keep with consistent policies and procedures, but there seem to be many more occasions where flexibility is king. Within certain constraints and with a good understanding of software development, it can be very advantageous to be flexible. In days with tight schedules, limited resources, and never ending requirements we must do what we can to thrive and create great software.
September 3, 2009
Service Oriented Architecture - SOA
One of the great buzz words we all see is SOA. Every person I talk to, describes it differently. Everyone thinks of different pros and cons when ever they extol the virtues of SOA. Some people always talk in terms of Web Services and SOAP, other always refer to service buses and queues. How can we concisely describe "What is SOA?"
and SOA Design Patterns
. Both are by Thomas Erl and are good studies of the basic concepts and ideas behind SOA.
- The design and architecture of the system must include services. Doesn't matter if these are web services, services subscribed to a message bus, or something else. They just have to be services.
- The services should push your design to be more modular, flexible, and not tightly coupled. Otherwise you might just be missing the point.
- When possible services should be as generic as possible, so they can be leveraged as much as possible. Specialized services are a must, but they should only be used when necessary.
- Not everything should be a service. If you find yourself trying to force something into a service, your probably trying to hard. If it doesn't naturally fit as a service, don't push it
and SOA Design Patterns. Both are by Thomas Erl and are good studies of the basic concepts and ideas behind SOA.
Subscribe to:
Posts (Atom)