I'm a software engineer. I've been calling myself one since 2003, my first application was built on a ZX Spectrum Sinclair in the late 1980's. After working with a variety of frameworks over the past number of years I can realistically say that I have never been more excited about software design than I am now.
Historically, software engineering has been viewed as a black hole by many corporations. Software engineering projects can often take years to develop, they can arrive well over budget, become delayed due to a variety of reasons and ultimately may not achieve what the customer envisaged. This is a common theme amongst many initiatives and can be attributed to a variety of reasons, under-scoping the project, not following proper standards, bad project management to name but a few.
Software is the only profession that I can ever see myself working within. It is the one profession where I can learn something brand new every day and receive satisfaction from approaching a problem in a different way, but achieve much better results each time; very few professions allow for this to occur.
Software engineering currently impacts all aspects of modern life from banking to medicine to publishing. Whilst only having been around since the 1960's the fact that it has introduced engineering disciplines into the software development process speaks volumes.
Software, by nature, is intangible; by intangible we mean that it is quite easy to observe the progress of a building or aeroplane whilst it is being built however it is difficult to gauge the same level of progress within a software engineering project.
According to Wasserman, software engineering practices have dramatically changed throughout the past number of decades. He suggested that there were eight fundamental notations in software engineering that form the basis for an effective discipline of software engineering.
Abstraction: Instead of jumping straight into a problem, trying to figure out the various minuscule details that eventually bog down any engineer in complexity, he recommends that we should step bag and simply concentrate on the core aspects of the problem. As a Ruby software developer I certainly feel that this method is being implemented through Behaviour Driven Development (BDD). BDD allows developers to simply focus on why the code should be created, rather than diving into the technical details, it also allows stakeholders to get more involved as they can understand the domain much easier.
Analysis and Design notations: Wasserman felt that there was too much misinterpretation and miscommunication between software engineers and stakeholders. He recommends the use of a standard notation to avoid such issues, UML and various other approaches have done much to make things as clear as possible for all participants involved in the process.
Prototyping: It has been said that a picture paints a thousand words, well a prototype prevents a thousand misconceptions from being formed. Prototyping allows for people to get a clearer picture about an application rather than just imagining it on paper. Clicking buttons on an interface, albeit dummy buttons, can have a profound influence on stakeholders. Many just like to see something that is tangible and something coming about after much discussion and business analysis.
Software Architecture: Software architectures play a major role in determining system quality and maintainability. Wasserman recommends a modular approach and expects that each unit should have a published interface. This is evident in the modern OOP world, by operating a divide and conquer approach, the application can be split into smaller modules allowing for developers to rapidly develop and test each seperate module.
Software Process: This is quite a simple concept. There is not a one size fits all, different projects require different processes. Some systems can be rapidly developed by one or two engineers whilst more technical projects may require teams of individuals across many levels working in conjunction. Within more complex projects, control is leveraged away from the developer and towards the project managers.
Reuse: Part of why I develop is to provide tools for myself, my team and others that can be re-used over and over again within many other applications. Developing a function, say an authentication system, which is used only once is very wasteful. Packaging the system as a plugin to be dropped into any future application is one which is happening more often within the Ruby world. This cuts down on overall costs, development and time to market.
Measurement: Whilst we previously discussed how software is intangible, there will always be discussion on how we can measure the status of the project. Some mention lines of code (LOC), others mention feature count. LOC is of course a spurious measurement, a function in Ruby takes 3 lines whilst it takes 20 lines in PHP. The goal should always be to write as small and fast an application as possible, the LOC metric only encourages people to write broken, sloppy and terrible code which is often unmaintainable. Ultimately what must be measured within a project is the outcome and not the output.
Tools: Wasserman mentions that we need tools to enhance software development. Such tools are constantly being developed. Plugins are constantly making life much more easier for developers, with the advent of meta-meta-meta programming we now have scripts that create code which creates code for a developer. Such tools allow for rapid development, ensuring that the wheel is not constantly being created.
Someone once said that with great power, comes great responsibility however the software profession is not regulated as much as the medical profession even though much of what an engineer can design can be directly used within medical practice. As a result, there are some bodies that exist who define what a practising engineer ought to know, based on their education and work experience. The Software Engineering Body of Knowledge (SWEBOK) is a product of the Software Engineering Coordinating Committee and is sponsored by the IEEE Computer Society and a number of other partners. Many claim that the document may not accurately reflect the community's view of software engineering and recognize the effort to try to define the profession. (ACM 2000). The body of knowledge just represents best known practice, it is not the perfect solution for everybody.
IEEE-CS and ACM 2004 implemented a joint initiative which guides insitutions of higher education on how to design curricula for undergraduate programmes in software engineering. The core body of knowledge is known as Software Engineering Education Knowledge (SEEK). This knowledge mainly includes relevant content from appropriate disciplines such as mathematics computer science, economics, engineering and software engineering etc.
There is no single right way to approach a software project. Each one is different, relying on the customers input, the development's team experience, etc. Overall, there is no substitute for experience and any tools or qualifications which extend the knowledge and ability of a software engineer can only be regarded as a boon. Too many software projects have become victim to feature creep, design bloat, excessive miscommunication and overdue deadlines. By equiping engineers with best practices and coding guidelines, an engineer can provide best value to the customer as well relatively straightforward hangovers between fellow software engineers. So what is the current state of software engineering? Well, the future is bright, software development on the whole is on the increase, new social mediums are allowing for bootstrapped startups to realize exceptional new ideas and develop them in rapid time.
Regulation will eventually come about within the software industry. Corporations tired of excessive bloat within their processes will ultimately combine together and enforce strict codes of conduct, in-depth peer reviews, and ultimately I thoroughly believe there will be a register of a Software Engineers performance throughout their career on various projects; a rate my software engineer if you will.
In this time of doom and gloom, software departments will be feeling the pressure to cut costs; cutting costs does not mean cutting quality, through new approaches and modern techniques software can be made rapidly and of high quality. Through enforcing and adhering to a code of ethics/standards, projects can avoid the bloat. The future is bright, the future is and will always remain within software engineering.
Comments [0]