.NET Software Engineering versus .NET Software Development
I have worked with a lot of great one-off development shops. Shops that reuse whatever they have available in the code library that is reusable to build new applications from. One of the hardest things to do is change the mind set of management and the development teams from one of software development to one of software engineering. Is there a difference?
Engineering is the difference. When I worked as an Electronic Engineer I was introduce to the engineering field. I believe that insight is what gives me the patience to accept engineering in software development. The engineering killer in our current market is "time to market". Well actually it is the perception that time to market brings to the table. Most shops believe the sooner code is being written for production the closer they are to being finished. Never mind performance, maintainability, reliably, security, and the rest of the quality attributes. Any shortcuts they can find in the design and analysis process are perceived to be an asset.
In engineering 80% of the effort is found in the documentation, the planning, the proof of concept testing, architecture verification and validation, and analysis and design. Don't get me wrong here, one too many documents developed during the process that wasn't needed to describe the application was wasted time. 20% of the time is put into developing a well designed application.
In one-off development it is the reverse, 20% of the time is spend doing the documentation, the planning, the proof of concept testing, architecture verification and validation, and analysis and design, and 80% of the time is spent developing (30% percent of which is spend debugging and shifting code design).
What most shops don't realize is that doing engineering correctly provides much more reusable code (it is cleaner and can be found easier), an application that is much easier to maintain and update, and an application with a lot less bugs, that performs better, and is much more secure. Engineering also provides the possibility of creating a reusable process that contains the metrics to do estimations instead of guess-tamations.
Not every shop should do software engineering. They may not be able to hire people with the skills required to pull it off because they aren't making applications that produce that type of revenue. They may have gurus (and they are paying enough to keep them on forever) who prefer agile development and they are producing high quality applications without the need for software engineering. They just don't want to. It's a shame, but "we just don't want to" is what I hear the most. They say they have been doing development like this since the dot com boom, then during their big layoff period, and now that they are stabilized once again, they see no need to change.
The problem that they don't see is that their development tools have changed. They are no longer scripting, or using VB 6.0 to crank out overnight applications. They are now using a fully capable OO/Component-oriented programming environment. To ignore this fact leads to worse spaghetti code in .NET applications, than it did in ASP2.0/3.0. Without engineering, you also loose the capability to take advantage of patterns correctly.
Will this Blog change anything out there? Doubtful, but it was something to type until Fear Factor started……
Engineering is the difference. When I worked as an Electronic Engineer I was introduce to the engineering field. I believe that insight is what gives me the patience to accept engineering in software development. The engineering killer in our current market is "time to market". Well actually it is the perception that time to market brings to the table. Most shops believe the sooner code is being written for production the closer they are to being finished. Never mind performance, maintainability, reliably, security, and the rest of the quality attributes. Any shortcuts they can find in the design and analysis process are perceived to be an asset.
In engineering 80% of the effort is found in the documentation, the planning, the proof of concept testing, architecture verification and validation, and analysis and design. Don't get me wrong here, one too many documents developed during the process that wasn't needed to describe the application was wasted time. 20% of the time is put into developing a well designed application.
In one-off development it is the reverse, 20% of the time is spend doing the documentation, the planning, the proof of concept testing, architecture verification and validation, and analysis and design, and 80% of the time is spent developing (30% percent of which is spend debugging and shifting code design).
What most shops don't realize is that doing engineering correctly provides much more reusable code (it is cleaner and can be found easier), an application that is much easier to maintain and update, and an application with a lot less bugs, that performs better, and is much more secure. Engineering also provides the possibility of creating a reusable process that contains the metrics to do estimations instead of guess-tamations.
Not every shop should do software engineering. They may not be able to hire people with the skills required to pull it off because they aren't making applications that produce that type of revenue. They may have gurus (and they are paying enough to keep them on forever) who prefer agile development and they are producing high quality applications without the need for software engineering. They just don't want to. It's a shame, but "we just don't want to" is what I hear the most. They say they have been doing development like this since the dot com boom, then during their big layoff period, and now that they are stabilized once again, they see no need to change.
The problem that they don't see is that their development tools have changed. They are no longer scripting, or using VB 6.0 to crank out overnight applications. They are now using a fully capable OO/Component-oriented programming environment. To ignore this fact leads to worse spaghetti code in .NET applications, than it did in ASP2.0/3.0. Without engineering, you also loose the capability to take advantage of patterns correctly.
Will this Blog change anything out there? Doubtful, but it was something to type until Fear Factor started……
posted by tadanderson at 4:48 PM
0 Comments:
Post a Comment
<< Home