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 development. Show all posts
Showing posts with label software development. Show all posts
December 2, 2010
November 30, 2010
C# Generics
A few days ago I was reviewing some old code that I had written a while back, and I found that I was having problems scanning the code quickly to see what it was supposed to do. After a couple a minutes, I realized that a number of areas in the code we're a little more verbose and confusing than they needed to be. The primary reason behind this: no generics. I know generics have been around for a while, and I have just gotten used to having them around. They make it much easier to deal with collections of objects in a type safe, and easy to follow manner.
Sure, before generics you could make things work, but in many cases I found myself having to cast object to a type, that I knew they we're. Now with generics, I just don't even worry about it. Everything just works, and that's good.
Sure, before generics you could make things work, but in many cases I found myself having to cast object to a type, that I knew they we're. Now with generics, I just don't even worry about it. Everything just works, and that's good.
November 23, 2010
ASP .NET Chart Control
I recently needed a chart in one of the asp .net website I've been working on. In the past I've never been able to find a satisfactory solution that was free or inexpensive. I was pleasantly surprised to find out that in Visual Studio 2010 and .NET 4.0, that Microsoft included new chart controls for ASP .net and for Windows forms. I figured that since they we're free and already included in C#, I might as well try them.
At first glance they appear to be pretty decent. The control includes most of the basic features that you would expect: multiple chart types (bar, line, pie), multiple series, 3D capabilities, legends. It also has a number of other features that we're well beyond what I was expecting for a free solution: advanced statistical calculations, and over 12 different categories of chart types.
My needs for the project I'm working on are very simple, so after a few minutes of looking at some examples (4 Guys From Rolla was a great starting point), I was up and running. Within a few minutes I had a basic line charts working, and shortly after that I had the legend, labels, and multiple series all working as well.
So far from what I've seen, these chart controls seem to work pretty well, even if someone had some intensive charting needs, these free chart control might still fit the bill. Definitely worth a look before buying anything to fill your charting needs.
At first glance they appear to be pretty decent. The control includes most of the basic features that you would expect: multiple chart types (bar, line, pie), multiple series, 3D capabilities, legends. It also has a number of other features that we're well beyond what I was expecting for a free solution: advanced statistical calculations, and over 12 different categories of chart types.
My needs for the project I'm working on are very simple, so after a few minutes of looking at some examples (4 Guys From Rolla was a great starting point), I was up and running. Within a few minutes I had a basic line charts working, and shortly after that I had the legend, labels, and multiple series all working as well.
So far from what I've seen, these chart controls seem to work pretty well, even if someone had some intensive charting needs, these free chart control might still fit the bill. Definitely worth a look before buying anything to fill your charting needs.
November 18, 2010
C# Lambda Expressions
For quite a while now I have been wondering about lambda expressions. I've started seeing more and more of them in code examples, and there has obviously been a lot of talk about them. But most of the examples I've seen have not been very intuitive. I finally decided to see what they we're all about, and was surprised about how simple they are to understand. They are not really anything new, just a new shorthand for doing things that C# could already do.
I started my journey be reading chapter 11 of Pro C# 2010 and the .NET 4 Platform
(As a side note I've read a number of the other chapters, and it looks like a decent book so far.) I thought it was interesting that lambda expressions we're grouped in the same chapter as delegates and events, but after reading the chapter, it all makes sense now. This is probably oversimplifying it, but lambda expressions are just "syntactic sugar" for creating anonymous functions, and working with delegates. They allow a developer to easily write a basic inline function for event handlers or anywhere else a delegate is needed.
The basic format for lambda expressions is arguments => statement. The expressions can have 0 or more arguments and 1or more statements. The most common case I've seen is probably one argument and one statement, and the nice thing about a single statement is that the result of the statement is the "return" value of the expression. One of the other great things about lambda expressions is that in most cases the parameters can be implicitly typed, so that can mean a few less characters to type, and simpler, easier to understand expressions.
I still don't know how often I will use them, but it is nice to know how simple they are and how easily I can define event handlers now. What would have taken a significant amount of boiler plate code and definitions and a function, can now be done in a single, quick line of code.
I started my journey be reading chapter 11 of Pro C# 2010 and the .NET 4 Platform
(As a side note I've read a number of the other chapters, and it looks like a decent book so far.) I thought it was interesting that lambda expressions we're grouped in the same chapter as delegates and events, but after reading the chapter, it all makes sense now. This is probably oversimplifying it, but lambda expressions are just "syntactic sugar" for creating anonymous functions, and working with delegates. They allow a developer to easily write a basic inline function for event handlers or anywhere else a delegate is needed.The basic format for lambda expressions is arguments => statement. The expressions can have 0 or more arguments and 1or more statements. The most common case I've seen is probably one argument and one statement, and the nice thing about a single statement is that the result of the statement is the "return" value of the expression. One of the other great things about lambda expressions is that in most cases the parameters can be implicitly typed, so that can mean a few less characters to type, and simpler, easier to understand expressions.
I still don't know how often I will use them, but it is nice to know how simple they are and how easily I can define event handlers now. What would have taken a significant amount of boiler plate code and definitions and a function, can now be done in a single, quick line of code.
November 11, 2010
Web Development with JavaScript and AJAX
It seems like JavaScript and AJAX are becoming more and more necessary to create professional, interactive web sites. Basic HTML and even CSS just won't cut it. People expect the "bling" that JavaScript provides. I have mixed emotions about JavaScript though. It can really make a website stand out, but compared to traditional languages and development environments, it can be a pain to develop, debug, and maintain.
Part of me would say that Silverlight or Adobe Flex provides a easier environment to develop in, but they can be very heavyweight for most web sites. Maybe I just haven't found the right JavaScript framework or toolkit that really works well and makes sense. It seems like jQuery and the Google Web Toolkit are two of the most common and well known systems. jQuery seems a little more flexible, and the Google approach seems to be very tightly coupled with Java. Since I do most of my development with C# and ASP .NET, jQuery looks like a more promising solution.
Part of me would say that Silverlight or Adobe Flex provides a easier environment to develop in, but they can be very heavyweight for most web sites. Maybe I just haven't found the right JavaScript framework or toolkit that really works well and makes sense. It seems like jQuery and the Google Web Toolkit are two of the most common and well known systems. jQuery seems a little more flexible, and the Google approach seems to be very tightly coupled with Java. Since I do most of my development with C# and ASP .NET, jQuery looks like a more promising solution.
November 9, 2010
Training Software Engineers
As I mentioned in my last post about hiring software engineers, I generally categorize software developers as either programmers or software engineers. Programmers have the basic skills to get the job done, but software engineers truly understand and apply all of the techniques and ideas that come with their craft.
Given the fact that no one is a perfect software engineer; how can we help train and educate team members to reach their full potential? Here are some of the techniques that I have used, but I would love to see what successes others have had as well.
1) PowerPoint Presentation Training
This is probably one of the most straightforward techniques, but one that I have the most mixed feelings about. I believe that this type of training is necessary and important. It can be very useful to get a group of people together to review, learn, and/or discuss something. But I also think that it can have the least overall impact of the different training ideas I have used. People tend to not participate much, so the presentation is very one sided, which means it's hard for attendees to focus.
2) One-on-one training
Sitting down with someone to review something specific, or explain something can be very powerful. Since the target audience is one, it is much easier to tailor the training to the individual, and they are much more likely to provide feedback and ask questions than in a group setting. This can happen formally as code reviews, targeted training, etc., or even informally as a brief discussion based on a question or comment. Sometimes I think the informal training, even though it is generally spontaneous, can be more effective than any preplanned training. With one-on-one interaction I find that the effect can be more dramatic than in group settings.
3) Training by Example
Another approach I use is to show developers good examples of how to be a software engineer. This can be including people in design discussions, reviewing "good" code, or asking them questions to help you work through a problem. This approach also works well, and is probably the least obvious form of training from the trainees standpoint. They may never know that they were being "trained."
Overall it seems to be one of the most difficult and important parts of my job: helping people reach their potential. It's a slow and time consuming process, but it can also be very rewarding for everyone involved.
Does anyone have any other techniques they use, or more ideas on how to improve or refine the ideas I already have? Also has anyone read any good books (or other resources) about how to manage software developers? I'm always looking for new ideas.
Given the fact that no one is a perfect software engineer; how can we help train and educate team members to reach their full potential? Here are some of the techniques that I have used, but I would love to see what successes others have had as well.
1) PowerPoint Presentation Training
This is probably one of the most straightforward techniques, but one that I have the most mixed feelings about. I believe that this type of training is necessary and important. It can be very useful to get a group of people together to review, learn, and/or discuss something. But I also think that it can have the least overall impact of the different training ideas I have used. People tend to not participate much, so the presentation is very one sided, which means it's hard for attendees to focus.
2) One-on-one training
Sitting down with someone to review something specific, or explain something can be very powerful. Since the target audience is one, it is much easier to tailor the training to the individual, and they are much more likely to provide feedback and ask questions than in a group setting. This can happen formally as code reviews, targeted training, etc., or even informally as a brief discussion based on a question or comment. Sometimes I think the informal training, even though it is generally spontaneous, can be more effective than any preplanned training. With one-on-one interaction I find that the effect can be more dramatic than in group settings.
3) Training by Example
Another approach I use is to show developers good examples of how to be a software engineer. This can be including people in design discussions, reviewing "good" code, or asking them questions to help you work through a problem. This approach also works well, and is probably the least obvious form of training from the trainees standpoint. They may never know that they were being "trained."
Overall it seems to be one of the most difficult and important parts of my job: helping people reach their potential. It's a slow and time consuming process, but it can also be very rewarding for everyone involved.
Does anyone have any other techniques they use, or more ideas on how to improve or refine the ideas I already have? Also has anyone read any good books (or other resources) about how to manage software developers? I'm always looking for new ideas.
November 7, 2010
Hiring Software Engineers
We recently went through a round of interviews for software developers where I work. Ever since then I've been reflecting on how to hire software developers. I wanted to outline some of the ideas that I have, and see if anyone has any feedback or other ideas.
1) Where to post job openings?
We have tried a number of different free and paid sites for job postings (state job sites, dice, careerbuilder, etc) , and most of them seem to be pretty hit or miss. We get a fair number of completely unqualified candidates, and only a few that are even worth interviewing. Does anyone have any other suggestions or ideas of where to find candidates? One of our most useful resources has been the local university, but that only works when we are looking for interns or recent graduates.
2) How to filter through resumes?
Many of the resumes we get are for individuals that aren't even experienced or trained in software engineering (Do people not ready job postings?). But after the first pass, here are some of the things I generally look for, other than some of the obvious ones:
3) How to interviewing candidates?
I wrote about a year ago on Job Interviews. I wanted to touch briefly again on some of the techniques that I use, and some of the areas that I continue to work on. Here are the key things that I want to get out of the interview:
With interns and candidates with little or no experience, I find that it is generally not too hard. Developers with 5+ years of experience seem to be much more difficult to interview. Most of this comes down to my belief that there is a significant difference between a programmer and a software engineer. A good programmer can be given a small to medium sized task, and can be expected to complete it in timely fashion, meet the requirements, and the end result will be decent code. The programmer focuses on getting the job done. A software engineer will do all of the same things, while at the same time taking into account overall business strategy and goals, code maintainability, design opportunities like refactoring, and many other things.
Trying to determine who has the experience, knowledge, and skills to really be a software engineer instead of just a programmer is no simple task. Given a finite amount of interview time, what things can you look for or ask about that can really help determine which category someone will fall into?
1) Where to post job openings?
We have tried a number of different free and paid sites for job postings (state job sites, dice, careerbuilder, etc) , and most of them seem to be pretty hit or miss. We get a fair number of completely unqualified candidates, and only a few that are even worth interviewing. Does anyone have any other suggestions or ideas of where to find candidates? One of our most useful resources has been the local university, but that only works when we are looking for interns or recent graduates.
2) How to filter through resumes?
Many of the resumes we get are for individuals that aren't even experienced or trained in software engineering (Do people not ready job postings?). But after the first pass, here are some of the things I generally look for, other than some of the obvious ones:
- Is the resume just full of keywords, instead of really focusing on skills that the individual has?
- What variety of projects have been worked in recent years (Web, back-office, database, etc)?
- How long does the candidate stay at jobs - are they a job hopper?
- Is the resume well organized and clear - or does it look like a computer generated it?
3) How to interviewing candidates?
I wrote about a year ago on Job Interviews. I wanted to touch briefly again on some of the techniques that I use, and some of the areas that I continue to work on. Here are the key things that I want to get out of the interview:
- Do they have a solid understanding of software engineering?
- Can they communicate well with others (even non engineers)?
- Can they analyze information and problems?
- Do they fit with the culture and environment of the company and the team?
- Are they dedicated and a hard worker?
- Can they lead a team and mentor other developers?
With interns and candidates with little or no experience, I find that it is generally not too hard. Developers with 5+ years of experience seem to be much more difficult to interview. Most of this comes down to my belief that there is a significant difference between a programmer and a software engineer. A good programmer can be given a small to medium sized task, and can be expected to complete it in timely fashion, meet the requirements, and the end result will be decent code. The programmer focuses on getting the job done. A software engineer will do all of the same things, while at the same time taking into account overall business strategy and goals, code maintainability, design opportunities like refactoring, and many other things.
Trying to determine who has the experience, knowledge, and skills to really be a software engineer instead of just a programmer is no simple task. Given a finite amount of interview time, what things can you look for or ask about that can really help determine which category someone will fall into?
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.
March 29, 2010
Java software development
From what I remember Java is about 15 years old now. Ever since it was released, Java has changed how we do software development. It was one of the first widely used and accepted "pure" object oriented languages. It was one of the best cross platform environments. Java byte code showed that an extra abstraction layer could perform well enough to be a viable option.
Many of Java's ideas and strengths have been copied by other languages and frameworks. These same languages have also learned from some of the mistakes that Java made. Even if Java doesn't become the end-all of software development languages, it will always have a place in history for it's impact on the development community.
Many of Java's ideas and strengths have been copied by other languages and frameworks. These same languages have also learned from some of the mistakes that Java made. Even if Java doesn't become the end-all of software development languages, it will always have a place in history for it's impact on the development community.
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 24, 2009
C# 4.0 and Visual Studio 2010
I've started looking into C# 4.0, Microsoft .NET framework 4.0, and Visual Studio 2010, hoping there will be some cool new features that I will like. I've done very little with some of the new features of .NET 3.0 and 3.5, and didn't notice much new with Visual Studio 2008. Here are some of the things I've seen that look intersting:
- Parallel Extensions for the .NET Framework: Now that most computers have 2-4 processors it is become more apparent that parallel programming will be going mainstream. Instead of being relegated to high end scientific and business applications on large supercomputers and distributed systems, every day programmers are going to need to know and use techniques for parallel programming. These extensions look like they are a step in the right direction. When combined with solid software development practices, these can get a developer headed in the right direction to be able to easily take advantage of the multiple cores available in computers today.
- C# optional parameters: One thing that I do miss from C++ is finally making it's way to C#. I can't count the number of times that I have had to create multiple different variations of a function, just to be able to mimic the capabilities of optional parameters. What could be 3 or 4 functions with slight variations in parameters, can now become a single method definition. Easier to maintain, easier to use, and much more convienenient. Plus by allowing named arguments, you don't even need to specify all parameters from left to right, you can pick and choose which parameters you want to set, when yo call the function.
- Static ID's for ASP .NET controls: I've always wondered why Microsoft decided to enforce their control naming on all ASP .NET developers. I could understand if the naming standard was the default, because it does enforce that all of the names are unique, but we are finally getting a way to specify the name we want. This will make my like so much easier, especially for JavaScript code and forms post-back. With multiple nested master pages and containers, the length and complexity of names for controls is ridiculous. I've actually had a few cases in JavaScript that I've had to create a lookup variable to map my usable names to the actual control names.
- Dynamic Programming and Dynamic Variables: I have to admit that I haven't done anything with the dynamic languages and features that already exist in .NET, and I don't intend to start now. I tend to prefer the enforced structure and design of normal development, but it is nice to know it is available if I want to give it a try.
October 17, 2009
Code Profiler for .NET
I've always been interested in profiling my C# code. Years ago with .NET 1.1 I used the DevPartner Profiler Community Edition, which is no longer available. Ever since then I have been unable to find a good free or open source solution for profiling .NET code. I know that there are some decent commercial products out there, but I'm cheap and I don't the tools often enough to merit purchasing them.
Is code profiling just not in demand? It seems like if enough people were interested in the value of profiling, then there would be at least one decent open source solution. For me it has been fun on occasion to really dig deep into an algorithm that I'm working on. Trying to eek just a little more performance out of it. I've found that disassembling the code also helps to see what is actually happening behind the scenes. One of the nice things about profiling .NET code is that you don't need to instrument the code manually. When I used the DevPartner ProfilerProfiler I just picked the options I wanted and clicked go. After running the application I could delve into the details of which functions were being hit the most, and even which lines of code were consuming the most time. It can be a challenge to tune the performance of an algorithm or an application, but it can be rewarding to the code double in speed, or even more.
Hopefully I'll be able to find a good open source code profiler to "get my fix" on performance tuning my code.
Is code profiling just not in demand? It seems like if enough people were interested in the value of profiling, then there would be at least one decent open source solution. For me it has been fun on occasion to really dig deep into an algorithm that I'm working on. Trying to eek just a little more performance out of it. I've found that disassembling the code also helps to see what is actually happening behind the scenes. One of the nice things about profiling .NET code is that you don't need to instrument the code manually. When I used the DevPartner ProfilerProfiler I just picked the options I wanted and clicked go. After running the application I could delve into the details of which functions were being hit the most, and even which lines of code were consuming the most time. It can be a challenge to tune the performance of an algorithm or an application, but it can be rewarding to the code double in speed, or even more.
Hopefully I'll be able to find a good open source code profiler to "get my fix" on performance tuning my code.
October 13, 2009
C# vs. C programming
For quite a few years now I've been working primarily with C# and Microsoft .NET, and I have to admit that even with it's shortcomings I would list them as my preferred programming language and development framework. I will admit that there are still cases where C and C++ are better/faster/etc., but overall I find that when I use C# I'm more productive, my code has fewer errors, and it is easier to maintain.
At my current job I get to work in both worlds. Most of the newer software we write is in C#, but we still have a pretty expansive set of libraries and applications that are in C++, we even have one that is in managed C++ (which has it's own set of problems). I always prefer working on the C# side of things, and even dread working with some of our C++ applications.
I know that for most people this is an almost religious topic, and I don't want to come across as a zealot, I just have my preferences. I've used C++ quite extensively and it is a great language, but C# builds on the long history of C and C++ and adds more than a few nice features. And since it is built on a decent framework (.NET) there is a greater consistency to code. When you change jobs in a c++ environment, you probably have to learn a new set of frameworks. Some companies use in house libraries, some use boost, and others use something else. With C# most of the basic framework pieces come built in. There will always be a need for other frameworks beyond that, but .NET comes with most of the necessities.
There are many other features and helpful things that come with C# and .NET, but my overall view is that when I use them, I am more productive overall, and that is money in the bank to me.
At my current job I get to work in both worlds. Most of the newer software we write is in C#, but we still have a pretty expansive set of libraries and applications that are in C++, we even have one that is in managed C++ (which has it's own set of problems). I always prefer working on the C# side of things, and even dread working with some of our C++ applications.
I know that for most people this is an almost religious topic, and I don't want to come across as a zealot, I just have my preferences. I've used C++ quite extensively and it is a great language, but C# builds on the long history of C and C++ and adds more than a few nice features. And since it is built on a decent framework (.NET) there is a greater consistency to code. When you change jobs in a c++ environment, you probably have to learn a new set of frameworks. Some companies use in house libraries, some use boost, and others use something else. With C# most of the basic framework pieces come built in. There will always be a need for other frameworks beyond that, but .NET comes with most of the necessities.
There are many other features and helpful things that come with C# and .NET, but my overall view is that when I use them, I am more productive overall, and that is money in the bank to me.
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.
October 2, 2009
Death to Internet Explorer 6
I personally think that Internet Explorer 6 should be outlawed. Web development can be difficult enough to make things look good and work right, that throwing Internet Explorer 6.0 into the mix just makes things that much harder. Even when I'm doing ASP .NET development, you would think that everything would work well with IE 6, but that is not the case.
I spend most of my time using Firefox to test my sites, then do some quick checks in either IE 7 or IE 8, depending on what is installed on the computer, and in most cases things look and work pretty well. Sometimes there may be a few tweaks necessary to get things just right. After that I have to spin up a virtual machine, or find an old computer with IE 6 on it. And that is where the fun begins.
Web page layouts never quite look right, IE 6 never really seems to do what you've told it to. It selectively ignores CSS and re-sizes things how it wants. The internet is abound with IE 6 CSS hacks. Functionality seems to have just as many problems. Basic JavaScript is hit or miss, it might work just fine, or it might decide to be your worst enemy. Anything more complex like AJAX is almost a lost cause. You might as well develop and maintain two separate websites: one for real web browsers and another for IE 6.
Maybe I'm being a little hard on the browser, but it really is a web developers worst nightmare. If there were only a few computers out there that still had IE 6, that would be one thing. But there is still a large portion of computers that run IE 6 as their primary browser. I defintely favor Firefox, but I don't mind if people want to use IE 7 or IE 8, just not IE 6. We should all wish it a fond farewell, and retire the old chap already.
I spend most of my time using Firefox to test my sites, then do some quick checks in either IE 7 or IE 8, depending on what is installed on the computer, and in most cases things look and work pretty well. Sometimes there may be a few tweaks necessary to get things just right. After that I have to spin up a virtual machine, or find an old computer with IE 6 on it. And that is where the fun begins.
Web page layouts never quite look right, IE 6 never really seems to do what you've told it to. It selectively ignores CSS and re-sizes things how it wants. The internet is abound with IE 6 CSS hacks. Functionality seems to have just as many problems. Basic JavaScript is hit or miss, it might work just fine, or it might decide to be your worst enemy. Anything more complex like AJAX is almost a lost cause. You might as well develop and maintain two separate websites: one for real web browsers and another for IE 6.
Maybe I'm being a little hard on the browser, but it really is a web developers worst nightmare. If there were only a few computers out there that still had IE 6, that would be one thing. But there is still a large portion of computers that run IE 6 as their primary browser. I defintely favor Firefox, but I don't mind if people want to use IE 7 or IE 8, just not IE 6. We should all wish it a fond farewell, and retire the old chap already.
October 1, 2009
.NET Code Coverage
I've been looking for a good, free code coverage tool for .NET for quite a while. I know that years ago NCover used to be pretty good, but the open source version appears to be dead, replaced by a commercial version. The old version still exists and works, but it's pretty outdated. Recently I've found PartCover but haven't had a chance to thoroughly try it out. Beyond that, I haven't been able able to find anything else that is open source or even free. But neither of these two solutions appear to have lots of active development going on, which I consider a pretty important metric when looking at adopting an open source tool or framework.
It seems surprising that their isn't more activity in the open source world in this area. There seems to be many other active communities in the open source world about C# and .NET. There are many projects like NUnit and NHibernate that are actively developed and extremely helpful. But there doesn't seem to be much open source activity about code coverage. Is this because people find that the commercial options available work well at a reasonable price? Or do people just not put much importance on code coverage?
I think that code coverage receives less attention than many other software development practices like unit testing, but it still seems like it would get more focus that it currently does. I hope that there is a code coverage tool out there that I just can't find, but I'm not holding my breath.
It seems surprising that their isn't more activity in the open source world in this area. There seems to be many other active communities in the open source world about C# and .NET. There are many projects like NUnit and NHibernate that are actively developed and extremely helpful. But there doesn't seem to be much open source activity about code coverage. Is this because people find that the commercial options available work well at a reasonable price? Or do people just not put much importance on code coverage?
I think that code coverage receives less attention than many other software development practices like unit testing, but it still seems like it would get more focus that it currently does. I hope that there is a code coverage tool out there that I just can't find, but I'm not holding my breath.
September 30, 2009
The Next Big Thing
I have to admit that I am constantly trying to think of The Next Big Thing: the next web fad, the next big technology, etc. I'd love to come up with the next Facebook or Google. Software is my passion, and I'm always trying to thing of new ways to use software to help people and/or make money. Most of my ideas never pan out, but it doesn't stop me from thinking of new ones.
I'll admit that it is a little optimistic to think that I'll come up with the Facebook or Google, but it would be so cool if I did. All I need to think of/invent/find out/predict the next big thing on the web. I find that it is easy to come up with ideas, but most of them are slight twists on things that already exist. Trying to come up with something truely unique and something that people want is not so easy.
Of course, part of what drives me is the thought of a potential revenue stream, it would be great to come up with something that generates income. But that is not my only draw. I just enjoy writing software, and if I can make a little extra money doing it, then even better. The last aspect is nerd cred. How cool would it be to be the next Mark Zuckerberg or Larry Paige.
Hopefully I'll come up with The Next Big Thing soon, but it's taking a lot of work.
I'll admit that it is a little optimistic to think that I'll come up with the Facebook or Google, but it would be so cool if I did. All I need to think of/invent/find out/predict the next big thing on the web. I find that it is easy to come up with ideas, but most of them are slight twists on things that already exist. Trying to come up with something truely unique and something that people want is not so easy.
Of course, part of what drives me is the thought of a potential revenue stream, it would be great to come up with something that generates income. But that is not my only draw. I just enjoy writing software, and if I can make a little extra money doing it, then even better. The last aspect is nerd cred. How cool would it be to be the next Mark Zuckerberg or Larry Paige.
Hopefully I'll come up with The Next Big Thing soon, but it's taking a lot of work.
September 29, 2009
Software Developer Job Interviews
At my job I have the interesting job of interviewing potential software developers. First of all it's much better to be on the interviewer side of the equation, but even then I see some pretty interesting things.
Some candidates that I've seen just seem so far off the mark, that it isn't even funny. I know that software developers have some very strong (and generally accurate) stereotypes about them, but sometimes I just have to laugh. I assume that when people are interviewing, that they put their best face forward. So when I see someone that is severely lacking in communication skills or that can't seem to think through a basic story problem I get concerned.
For hiring software developers, I generally look for two main things. First is technical experience and knowledge. The candidates I hire need to have a respectable 4 year degree in Computer Science and/or years of on the job experience. Of course a lot of this depends on the level of candidate I'm looking for, but there has to be something. Much of this technical background can be gleaned from a resume, unlike the second thing I look for: communication skills.
Like I said before, I know that there are many well deserved stereotypes about software developers, and one of them is lack of communication skills. But even between developers there can be a huge difference in this area. Some people that I have interviewed (and sometimes worked with) can't even communicate well with other techies. They speak in a language that is all their own, that others can barely understand.
If someone passes the smoke test for both of these items after a brief phone interview, then I will generally consider a face-to-face interview. One thing that I like to use during an interview is word problems or Puzzles
. These help me to get some insight into how people think, communicate, and even respond to pressure. And it's not all about getting the correct answer, although that helps.
Some other resources that I have found to be useful both as an interviewer and interviewee is Programming Interviews Exposed
. It isn't a magic bullet, but it has helped me as an interviewer to get a different view on things. Some of the ideas they present are a little extreme, but still provide some insight.
Some candidates that I've seen just seem so far off the mark, that it isn't even funny. I know that software developers have some very strong (and generally accurate) stereotypes about them, but sometimes I just have to laugh. I assume that when people are interviewing, that they put their best face forward. So when I see someone that is severely lacking in communication skills or that can't seem to think through a basic story problem I get concerned.
For hiring software developers, I generally look for two main things. First is technical experience and knowledge. The candidates I hire need to have a respectable 4 year degree in Computer Science and/or years of on the job experience. Of course a lot of this depends on the level of candidate I'm looking for, but there has to be something. Much of this technical background can be gleaned from a resume, unlike the second thing I look for: communication skills.
Like I said before, I know that there are many well deserved stereotypes about software developers, and one of them is lack of communication skills. But even between developers there can be a huge difference in this area. Some people that I have interviewed (and sometimes worked with) can't even communicate well with other techies. They speak in a language that is all their own, that others can barely understand.
If someone passes the smoke test for both of these items after a brief phone interview, then I will generally consider a face-to-face interview. One thing that I like to use during an interview is word problems or Puzzles
. These help me to get some insight into how people think, communicate, and even respond to pressure. And it's not all about getting the correct answer, although that helps.Some other resources that I have found to be useful both as an interviewer and interviewee is Programming Interviews Exposed
. It isn't a magic bullet, but it has helped me as an interviewer to get a different view on things. Some of the ideas they present are a little extreme, but still provide some insight.
September 28, 2009
The Future of Computer Software Development
What does the future of software development hold? Even over the last few years I can think back to how much more difficult the day to day tasks of software development were. Writing a Java GUI application was painful, using source control was difficult, testing code was error prone. All of these things and many more tasks seemed to take up a lot of my time.
To be honest not all of these things have gotten easier. But many great tools and methodologies have come along that make many of the tasks we perform each day much easier. They allow me to spend less time on the mundane tasks so that I can focus on what I enjoy: developing software. I find that more and more of my day can be spent on system architecture, software design, and actual coding.
Some of the specifics that I think of are: Visual Studio
and Subversion
. Visual Studio can be a pain to learn to use well. There is a steep learning curve, but I find myself somewhat dependent on the tools and help that it gives me. I know some people will think that this is a bad thing, but overall I find that it makes me more productive. Subversion makes my day so much easier. Most of the other source control systems I have used are not very smart, and not very easy to use.
At the heart of things I still know that software development is not easy. Regardless of the tools at hand, more powerful languages, any anything else that has come along, it still takes skilled engineers with solid development practices and procedures to write good software. But will this change in the future? Will some new tool or language some along that is so revolutionary that software development will be easy? I don't believe so.
Some tasks might continue to get easier, but in the end you will always need experienced and educated software developers to do the work.
To be honest not all of these things have gotten easier. But many great tools and methodologies have come along that make many of the tasks we perform each day much easier. They allow me to spend less time on the mundane tasks so that I can focus on what I enjoy: developing software. I find that more and more of my day can be spent on system architecture, software design, and actual coding.
Some of the specifics that I think of are: Visual Studio
and Subversion. Visual Studio can be a pain to learn to use well. There is a steep learning curve, but I find myself somewhat dependent on the tools and help that it gives me. I know some people will think that this is a bad thing, but overall I find that it makes me more productive. Subversion makes my day so much easier. Most of the other source control systems I have used are not very smart, and not very easy to use.At the heart of things I still know that software development is not easy. Regardless of the tools at hand, more powerful languages, any anything else that has come along, it still takes skilled engineers with solid development practices and procedures to write good software. But will this change in the future? Will some new tool or language some along that is so revolutionary that software development will be easy? I don't believe so.
Some tasks might continue to get easier, but in the end you will always need experienced and educated software developers to do the work.
Subscribe to:
Posts (Atom)