Month: August 2016
Learning AngularJS
Just finished a class on AngularJS. The title of the class was Developing Web Applications Using AngularJS. It was a four day class and the instructor was Brad Gillespie who was a very good instructor. Overall, I have to admit it was a pretty good class that provides an overview on the basics of using angularJS on the client side for web applications, which fit in perfectly for where we’re at with regards to our system.
We are currently in the process of remodeling our legacy Classic ASP web application into several .NET web applications. We’re using .NET WebApi 2.x for restful services and .NET/MVC 5 and angularJS for client side applications.
For the restful web services we’re breaking those into several applications by function, which at the moment is by main menu classification. We’ve created three client side applications, one for admin, education institutions, and educators.
For the end user, there is little difference in the appearance of the system. The menus, page headers and footers are the same as the original application. As we replace existing pages we’ll be able to remove them from the legacy application.
I estimate the remodeling or rewrite will take about seven years to complete when we consider enhancements, bug fixes and changes we’ll be required to make because of changes in state and federal laws.
This is a picture of the certificate that says I completed the class.
Forget Technical Debt — Here’s How To Build Technical Wealth
Great article published in People & Culture Magazine, found this article on Flipboard August 11, 2016. Forget Technical Debt — Here’s How To Build Technical Wealth
How does one approach legacy code? Andrea Goulet and business partner Scott Ford love legacy code. Andrea and her team believe people are more than just makers, they are menders too!
Here’s 3 paragraphs from the article I think describe most of the development efforts I’ve been involved in over the years.
Sure, it might not make sense to test compulsively when you’re pushing toward a prototype. But once you have a product and users, you need to start investing in maintenance and incremental improvements. “Too many people say, ‘Don’t worry about the maintenance, the cool things are the features!’” says Goulet. “If you do this, you’re guaranteed to hit a point where you cannot scale. You cannot compete.”
As it turns out, the second law of thermodynamics applies to code too: You’ll always be hurtling toward entropy. You need to constantly battle the chaos of technical debt. And legacy code is simply one type of debt you’ll accrue over time.
“Again the house metaphor applies. You have to keep putting away dishes, vacuuming, taking out the trash,” she says. “if you don’t, it’s going to get harder, until eventually you have to call in the HazMat team.”
I see this a lot. Start on a new system and the initial focus is to get it working and usable and no one is really concerned with the structure of the system or how the code looks as long as it works. Once the initial system is working, work on fixing bugs and implementing enhancements. The end result is, we never go back to refactor the code base, especially the parts that could be promoted into base classes and generalized to help move towards following the basic principals defined in the SOLID acronym.
It’s an easy trap to fall into because management is focused on moving forward with new development and as long as the system works, why go back and take time to improve the code base that no one sees but the developers.
Whenever we started a new application, I had one director who would always say, “every project has a start and a finish”. Once it’s finished the application goes into maintenance mode not to be touched again unless absolutely necessary. Once an application was delivered to production we spent the next several months fixing bugs, after that the system wasn’t looked at again.
One of the short comings of that thought process was the lack of understaning how everything worked or fit together. There wasn’t time to create technical wealth. The director couldn’t understand how working on one application could benefit all applications in the system. They were missing the point about software development and not looking at the big picture, which makes is worth quoting the following statement from the article.
I know it’s hard to go back and refactor code once because it seems like you’re spending too much time on one area of code. If the system is around long enough there are parts that will need to be revisited several times to keep it going and making it better so you won’t need to rewrite it from scratch in five or six years.
It’s like a house, when the foundation and the frame are solid and flexible, it has a better chance to survive anything bad happening around it.