20 Subjects Every Software Engineer Should Know

Here are the most important subjects for software engineering, with brief explanations:

1.Object oriented analysis & design: For better maintainability, reusability and faster development,  the most well accepted approach, shortly OOAD and its SOLID principals are very important for software engineering.

2.Software quality factors: Software engineering depends on some very important quality factors. Understanding and applying them is crucial.

3.Data structures & algorithms: Basic data structures like array, list, stack, tree, map, set etc. and useful algorithms are vital for software development. Their logical structure should be known.

4. Big-O notation: Big-O notation indicates the performance of an algorithm/code section. Understanding it is very important for comparing performances. 

5.UML notation: UML is the universal and complete language for software design & analysis. If there is lack of UML in a development process, it feels there is no engineering.

6.Software processes and metrics: Software enginnering is not a random process. It requires a high level of systematic and some numbers to monitor those techniques. So, processes and metrics are essential.

7.Design patterns: Design patterns are standard and most effective solutions for specific problems. If you don't want to reinvent the wheel, you should learn them.

8.Operating systems basics: Learning OS basics is very important because all applications runs on it. By learning it, we can have better vision, viewpoints and performance for our applications.

9.Computer organization basics: All applications including OS requires a hardware for physical interaction. So, learning computer organization basics is vital again for better vision, viewpoints and performance.

10.Network basics: Network is related with computer organization, OS and the whole information transfer process. In any case we will face it while software development. So, it is important to learn network basics.

11.Requirement analysis: Requirement analysis is the starting point and one of the most important parts of software engineering. Performing it correctly and practically needs experience but it is very essential.

12.Software testing: Testing is another important part of software engineering. Unit testing, its best practices and techniques like black box, white box, mocking, TDD, integration testing etc. are subjects which must be known.

13.Dependency management: Library (JAR, DLL etc.) management, and widely known tools (Maven, Ant,  Ivy etc.) are essential for large projects. Otherwise, antipatterns like Jar Hell are inevitable.

14.Continuous integration: Continuous integration brings easiness and automaticity for testing large modules, components and also performs auto-versioning. Its aim and tools (like Hudson etc.) should be known.

15.ORM (Object relational mapping): ORM and its widely known implementation Hibernate framework is an important technique for mapping objects into database tables. It reduces code length and maintenance time.

16.DI (Dependency Injection): DI or IoC (Inversion of Control) and its widely known implementation Spring framework makes life easy for object creation and lifetime management on big enterprise applications.

17.Version controlling systems: VCS tools (SVN, TFS, CVS etc.) are very important by saving so much time for collaborative works and versioning. Their logical viewpoint and standard cammands should be known. 

18.Internationalization (i18n): i18n by extracting strings into external files is the best way of supporting multiple languages in our applications. Its practices on different IDEs and technologies must be known.

19.Architectural patterns: Understanding architectural design patterns (like MVC, MVP, MVVM etc.) is essential for producing a maintainable, clean, extendable and testable source code.

20.Writing clean code: Working code is not enough, it must be readable and maintainable also. So, code formatting and readable code development techniques are needed to be known and applied.

5 Common Antipatterns in Software Project Management

Overplanning/analysis/meetings:

Some companies or project teams falls into error of spending time for the project planning & analysis & meetings much more than needed. Planning detail is not needed to be "complete" in each phase. This may be a serious bottleneck for projects. Like planning, analysis is also not needed to be complete at the beginning, except waterfall projects. As we know, waterfall is not such an efficient software process/methodology, until there is not a contract obligation about that. Planning and analysis should be "as required" and have flexibility points. Also, meeting duration and intervals are very important about this concept. Only required meetings with required staff and with shortest possible duration should be performed. Otherwise a huge time loss and unnecessary brain fatigue on staff will be inevitable.

Project mismanagement:

Most employees like working in a relaxed environment and company. But on the other hand, if their work is not monitored and controlled, they are also not satisfied. Monitoring and controlling is required for non-managers because they need to be directed (they are not employer and they don't have to make every important decision), leaded (code reviews, trainings etc. are important for self development, also scheduling is important for efficiency) and appreciated (high performance and skills needs good feedbacks, at least a few good words). And they also want to know that they are doing an important job and they are part of that organization. So, an ethical staff will also require to be managed and controlled "as required".

Wrong choices of staff motivation techniques:

Job satisfaction (passion for the job concept, learning and self-development), human interactions (between employers and employee) and income (convenient with job type and sector averages) are very important for staff motivation. Job details, development plans, income and midterm income possibilities must be explained before starting job and if everything is OK, they must not be changed after starting job. Beyond the technical and economical issues, communication is the most important concept in teamworks. IT staff is not a kind of people that can be motivated using hard wording, hierarchical and forbidding working style. They should feel confidence and comfort. After that, performance will be OK. If these things cause inactivity on staff, those staff is not right choice and an action must be taken as soon as possible.

Wrong selection of metrics and evaluation methods:

Metrics are important tools for monitoring software development process and they can provide some different viewpoints. For example, widely used "line of code" (especially logical line of code LLOC) metric may be used for "monitoring the growth of project by code size". If you attempt to evaluate developer efficieny using LOC, this will be a huge mistake because short and efficient code, design patterns etc. will be punished. Also copy paste programming, unreadable code etc. will be rewarded. E.g. cyclometic complexity, scheduling compliance, bug count are better methods. But best of all is determining right metrics according to the project type and team member properties.

Documentation strategy mistakes

Documentation is very important for software projects. Planning, analysis, design, development and testing phases need "required" level of documentation. Even for some fastest agile processes like SCRUM, documentation is needed. Main purpose of documentation is making life easier for developers and users. For example use case definitions are important on development phase, complex problem solutions are important on maintainance phase or on employee shifts, diagrams are important for understanding concepts fast and clearly. However documentation should not consume a very important percentage of whole project schedule. Generally it may be %5-10.

Software Architecture Antipatterns : Swiss Army Knife Interface

Swiss Army Knife Interface is an interface class which has excessive number of method definitions. Architect/designer may design this interface to use for every need of the software, but this is a wrong approach and an antipattern. More than one interface must be designed using some design approaches.

Of course, "excessive number of methods" is a too general statement. Although most developer think that a handful number of methods (e.g. 8-10)  and some studies show that some magic numbers (7 plus/minus 2) are mostly enough, we can't say the maximum number of methods precisely. 

First of all, you must think that this interface will be implemented by a class and if the number of methods is excessive, there will be plenty of empty method bodies in implementor class. But this situation still can't determine the number of interfaces and number of methods in an interface.

The answer is hidden in the OOP SOLID rules. Single Responsibility ("S") rule of SOLID says that "every object should have a single responsibility", and Interface Segregation ("I") rule of SOLID says that "different types of functionalities should be placed in different interfaces". If an interface have more than one types of functionalities or defines more than one responsibilities, implemening that interface is meaningless because implementer class will not suit SOLID rules by implementing that interface. 

More than one Swiss Army Knife Interface may also exist in a software. This means more than one problem exist and must be solved. 

For another viewpoint, you can take a look at our another post about interface segregation principle:

http://codebuild.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html

Sofware Management Antipatterns: E-Mail is Dangerous

Using e-mail is an important communication tool in software companies, but performing communications mostly with e-mail is dangerous. In this post, this issue will be detailed together with common e-mail mistakes. This information can be generalized for most types of companies.

E-mails may be used for some kind of situations:

• For sending a report, meeting record etc. which is not confidential, to a manager or a group.
• For sending a short message which is not urgent, to a person who can’t be accessed via telephone and face-to-face.

E-mails should NOT be used for these situations:

• For confidential messages and criticisms: E-mails can be distributed to other people or large groups easily, so this is not a good idea.
• For situations  which could be used as evidence in a court of law : For example, if you say “We will do X item in a month” to the customer with e-mail, it can be a mandatory item for you in the next days.
• For explaining a complex topic: It will be time consuming to write hundreds of words. Speaking will be more effective.
• For explaining an important, sensitive topic: Word emphasis, voice tone, gestures and mimics are very important for conversations. E-mails have none of them and this may cause misunderstandings.

And some e-mail suggestions:

•  Don’t use e-mail bodies as title, this is ridiculous:

Title: Please send me a report about X task.
Body: nothing

•  Don’t put hundreds of people to your e-mail’s “TO” or “CC” list. Use BCC. Otherwise all people and spam softwares will know all e-mails:

To:a1@a.com, a2@b.com, ... , a1000@z.com
CC:a1001@z1.com, …, a2345@zz.com

• Don’t use infinite forwards for e-mails. These type of mails are not funny for most people.

To: hundreds of people
Title: FW:FW:FW:FW:FW:FW:FW:FW:FW:…

• Don’t use e-mails as FTP. Use a file transfer protocol for sending messages larger than a few MB. A common wrong usage:

Attachments: AnImportantDocument.pdf (123 MB)

• Don’t use e-mails as a version controlling system. Manage your documents with a real version controlling system:

Attachments:  “CustomerReport_last_20122010_newest_veryVeryLast_1_1.doc”.

• Don’t use so many smiley images, big signature images, long signatures, colorful decoration templates in your e-mail. These are generally disgusting and unnecessary. Besides, they will increase network load.

Sources:

·         http://sourcemaking.com/antipatterns/e-mail-is-dangerous

·         http://www.dzone.com/links/r/if_you_do_this_in_an_email_i_hate_you.html

Software Antipatterns : The Golden Hammer

Preface 

A "software pattern" is a predefined and accepted solution for a specific software problem. Similarly, a "software antipattern" is a predefined and accepted unsuccesful solution. It's known as a bad solution, and should not be used.

The Golden Hammer Antipattern

The Golden Hammer can be defined as an architecture, a solution or a software tool that is believed to be the best solution for every software problem/project. 

If a software team had successful experiences with a software architecture, tool or solution they may want to use that in every other problem/project. Especially if that experience had a success in the past, this probability will be higher. Or if that experience had been costly for the company and new experiences will be more costly, managers may not give resource for new techniques.

There can be other causes: The software team either don't want to learn new technologies and techniques, so they want to use their "known" technology/technique in every problem or they are not aware of the growing world of technology and new solutions.

For example, "using well known software patterns in every software project" is a golden hammer antipattern. Because of one or more causes told before, this approach can be used and probably will be harmful for the software. And maybe it will not be corrected in the future because of project calendar.

Eventually, each software problem/project is different is its own context. And must be evaluated in its own cases. Using same approaches for every problem is dangerous.