Top 3 Software Engineering Principles

Question

I know what I was taught in my Software Engineering Courses at school, I know what i was taught in my first year of being a software engineer, and years later I now can understand what is important in software development.

If you could only teach 3 software principles/philosophies to a entry level software engineer, what would they be? And why did you choose them ?

Common Software Development Philosophies

---

My top list would be:

1. Kaizen
   I read this once, and it pains me I can't remember where, but they related Kaizen to bug fixing. Any time you find your self fixing a bug, it talked about fixing the other code around it. A lot of times bugs are a direct result of bad code. When it comes time to stop the bleeding, people just stick on a band aid.. they don't think about disinfecting the areas around it.

2. Good Enough
   I once worked at a client that had multiple projects all lead by different consulting companies.

   Our company produce a "good enough" designed product that balanced: leveraging bleeding edge technologies, functionality, and most importantly the project plan. We delivered a functional product, on time. It did everything that was asked, in a basic way. We then worked on beautification.

   Another company, full of Microsoft MVPs, developed a product that was bleeding edge, completely beautiful,and months behind schedule. On top of being late, the use of too new technology and attention to too much UI detailed left a product that was over designed and buggy.

   The concept is to know when to cut corners, and when to get something working correctly, and then going back and polishing it up... if needed of course.

3. YAGNI - (You aren't going to need it)
   This one relates to keeping systems simple. Countless times I have seen clients implement things for future use, and by the time the future gets there it is completely wrong, un-maintained, or poorly documented. Sometimes its better to keep things simple and only implement what is required now.

Note: Once my question gets old enough I will offer a bounty, and the highest voted answer will get the points.

Answer 1

Here's a few that come to my mind:

1. Your first version of anything will have corrections, changes, or adjustments and this is OK. You don't have to be perfect right off the bat. This could be viewed as a "Version your Perfection" and is something that I wonder how well is this understood generally. Accepting imperfection can be a challenge for some people is another way to view this.

2. Know yourself. What are your strengths? What are your weaknesses? What are those things that give you a high? What frustrates you to no end? This includes knowing how you learn but also what kind of work do you prefer and what environmental structures work best for you. At times it scares me how this isn't taught but yet so should be taught in schools so that we have this to help us find work that suits us in many ways.

3. How to Win Friends and Influence People has some good principles that can be quite useful if people just knew them and cared to some extent as I wonder how well handling others is taught in schools these days.

SDLC would be something that I'd probably add if needed but this should be known for anyone getting into the field in a sense.

Answer 2

For me, that'd be:

KISS "Keep it simple, stupid!" I know lots of people that think about the possible challanges a piece of code will go through in the future and try to incorporate all that into it's design. From my experience, these guesses (and they are nothing more than that) are usually not the least bit accurate. I think that keeping something as simple as possible for solving the problem at hand leads to better solutions. That works in other areas as well, e.g. litarature: If you can take words away without changing the meaning, do it.

The UNIX philosophy Essentially it comes down to: Write code that does one thing and does it well. I don't like to use large frameworks that solve hundreds of problems just because I have one particular of these problems. I'd rather use a hundred libraries if I have a hundred distinct problems - if they are all designed to solve just that problem and nothing else, they are more likely to know what they are doing and take it seriously. A framework for user interfaces, however, may take their database access code less serious.

Rapid Application Development I've been involved with elaborate software development planning procedures and I often noticed that both people specifying requirements and suggesting solutions frequently change their mind if they see a possible solution in action. Therefore, the "in action" part is often the first thing I do: Implement a prototype of an idea and evaluate it a bit. If it's still cool, implement proper business logic and solve all the nice detail problems. If not, throw it away.

Answer 3

Unless your core business is wheel invention, don't set out to invent wheels.

This means spend the time to learn what tols are already out there that you can leverage in your business. Select languages, libraries and technology stacks that are mature and already address as many of your needs as possible. Not only that, but learn established best practices and coding standards. 'A poor workman blames his tools' is true largely because good workmen know to only use the best tools. Focus on what your core competencies are and where you can add unique value.

Once you have done this, then you will be in a position to make your own unique contributions, identify new solutions and implement them with confidence and authority.

Answer 4

Step 1 Make it work. There is always a core of required functionality, implement it. Even if you don't get any farther, you have some thing that works and is useful.

Step 2 Make it work right. Debug, refactor and add required features you missed in Step 1. Some customers maybe happy if you stop here.

Step 3 Make it pretty. Take the bare bones UI from Step 2 and make it user friendly and esthetically pleasing.

Answer 5

1. Write a Spec First. Even a simple one on a piece of scrap paper. It's easier to debug logic problems on paper than once you're coding. It reminds you what you need to do, and most importantly, what you don't.
2. KISS. Keep It Simple, Stupid.
3. Learn. Each different piece of technology or methodology you learn is another tool in your toolbox. Having a large toolbox is essential, because every technology has a strength and weakness. Knowing which tool to apply to which problem can save you a ton of time.

Answer 6

1. Think twice, run once especially on Deletes and Updates in a database

2. Remember that the person likely to be using the program is NOT you and its a "thing" that they have to use to get THEIR job done. The software you are creating is NOT interesting to them as software. It just works on their pc - right =>

3. Learning to communicate with all people is the best skill in getting things done. Learning the soft skills is as important as the programming knowledge. People get things done not computer progams.

Answer 7

Since this is about Engineering, I think it's good for them to learn about the "real world" where things get built, not just thought about.

1. Keep It Simple: easier to design, build, debug, maintain. In other words, the cost of development and ownership will be lower.

2. People, Time, Money: you can't create a realistic schedule without knowing your three factors. How many people are on the project (and sometimes it helps to know which people), how much time you have (deadlines, milestones, etc), and how much total $$ you have to spend. If nothing else, you need two out of three to determine the third value.

3. Theory vs Practice:

In theory, there is no difference between theory and practice. In practice, there is.

Answer 8

I would prefer these 3 :

1. The Myth of Genius Programmer.
   I 100% agree with Brian Fitzpatrick and Ben Collins-Sussman when they talked at Google I/O 2009. Some great points were : There's no genius programmer, bus factor, version control and team development. I think this "Genius Programmer Myth" is important to be taught first at college or to entry level developer. The "heroic programming" era has gone by. No great software comes from solo programmer anymore. Great software comes from bunch of programmers that collaborate together.
2. Design by Contract
   To allocate jobs to each programmer and to make sure these programmers doesn't do any "heroic/satanic things", we need some contract, preconditions, postconditions etc. And based on these things, we design the software.
3. Test Driven Development
   Last thing, it's always a good habit to write down test cases before any algorithm/function/procedure/method/class get implemented. Of course, programmers don't need to know what are the test cases are.

Answer 9

1. YAGNI / KISS ... same spirit, the first one tells you why, the later tells you how ;)
2. Kaizen
3. SOLID - only to be used to help you achieve 1 and 2.

If we had 4, I'd add TDD. That said, I do rank the 3 above higher.

I didn't know Kaizen by a name. I heard it from an uncle bob's key note, where he was speaking about software craftsmanship. The way he said it, is to always leave the code a little bit better than when you checked it out. It doesn't only applies to bug fixing, but on each task you do. You can be adding some features to an existing system, and when doing so you should improve the code you are working with. Small improvements, so the code is always better. Is by far more achievable than a huge redesign.

Answer 10

1. Write a spec
2. Get the spec reviewed
3. Find a good tester - your code is as good in quality as your best tester (not really a programmers job, but it helps if they appreciate test as an important part of software development)

Answer 11

1. Don't repeat yourself.
2. Don't use a hammer as a screwdriver.
3. Don't use a nuclear bomb when you need a lighter; don't use a lighter when you need a nuclear bomb; and know the difference.

Mostly they all imply that you know what you're doing before you do it.

Answer 12

1. KISS - Keep it simple. complexity always comes backs to bit you in the ass.
2. SOLID - Adhere to the SOLID principles. Enough said.
3. LEARN - Learn, learn, learn. Everything else takes care of itself.

Answer 13

1. Prefer flexible software over perfect software. If your software is perfect now, but impossible to extend, it won't be perfect anymore next year. If your software is flexible, you will always be able to extend it further, as long as you keep it flexible.

2. Remember that debugging is harder than writing code. If you try to be as smart as possible in writing your code, how are you ever going to debug it. Prefer readable code that's spread over 10 lines, rather than smart code that is written on 1 line.

3. Learn from your mistakes. Once you solved a problem, ask yourself: why did the developer that wrote that bug, was able to write that bug? Is there anything that we can do to prevent these problems for appearing again?

Answer 14

1. Code humbly: you aren't the best. Find out who is and learn from them.
   • Always have doubts about your code.
   • Don't assume you know more than anyone else.
   • Someone else has already come up with a better solution. Find it.
2. Don't repeat yourself: if it's not DRY, it's not OOP. Try again.
   • DRY code is maintainable code.
   • It's done right when you can read it like a book.
3. Develop for the future: band-aids don't last forever.
   • Too many people code as if there's no tomorrow.
     • But tomorrow, their code sucks.
   • Make sure your code doesn't suck tomorrow.
   • Code how you wish the people before you coded.
   • Document how you wish the people before you documented.

It was hard to come up with 3 distinct principles; I think thoughtfulness is the main idea here.

Answer 15

1) Make sure you perform a thorough analysis before you act.

This sounds too rudimentary to be useful, but I've been around a long time, and a significant number of the failed architectures, designs and defect "fixes" I've seen are a result of the engineer not understanding what they were doing before they began the work. If you find some odd code, then find the person who wrote it, and then ask them why they did it that way. They will almost always include in their explanation some incorrect theory about the behavior of the system and/or the requirements for it.

2) Optimize the right things.

Engineers tend to optimize too early. They are often tempted to optimize on the fly when they see "obvious" opportunities. But almost every optimization removes degrees of freedom from a design, that is, it makes certain operations more efficient at the expense of making others more difficult. Done too early in development, before all the elements are in place, this can create situations where the least probable operations have been optimized and the most probable have been made difficult to use. Even worse, poor analysis (see #1) generally means that engineers optimize what they know (by some pattern or rule of thumb) and end up making it difficult to optimize the actual bottlenecks when they arise.

3) Getting the software to "work" is the first, least difficult step.

Engineers fall prey to this all the time. In my time, I've had a lot of engineers tell me they are "done" when they deliver a feature. But implementing a feature is the easiest step. Having the implementation done correctly: tested, optimized, scalable, localizable, maintainable, etc, is what takes all the work (and theoretically why engineers are paid more than programmers). In general, these requirements cannot easily be met "later", as management tends to prefer. And failure to meet all of these requirements early on is the main reason why software teams working on a project lose their efficiency over time and eventually grind to a halt.

Answer 16

Probably not 'top level' principles but:

1. Make sure you can read your own code in a few months from now. It's in fact harder to read code that it is to write (your own) code. Use meaningful class and variable names, have other developers review the code make they understand it (add comments etc.).

2. Each time you discover a bug write an automated test for it. The more automated tests you have, the more confident you will be that fixing something else did not suddenly re-introduce the first bug again.

3. Implement the simple version first and make it more general later (if you need it).

Answer 17

1. Design it first Spend time with something like a pen and pencil, visio, omnigraffle, (maybe even photoshop but that is very slow hence omnigraffle). But dont get you head stuck down in code you lose the big picture and will end up using only half the code you wrote. Making a good simple design from the start is going to save a lot of headaches.

2. YAGNI So keep it simple So agree in this, there is always a simpler way, spend some time writing a nice piece of code than just coping and pasting rubbish.

3. COMMENT YOUR CODE I think about 6 months in the future I will be reading this code again and wondering why I did something. So I write my comments as if I am sending a message to "future me". I even leave fun comments to see how I am going.

Answer 18

1. STOP - Shall a thought of a better way to do something crosses your mind, stop and really consider it. Ignoring that thought usually backfires.

2. DOCUMENT - and I'm NOT talking about - mergesort(int[] arr) //this method uses merge sort algorithm to sort...... NOT. I'm talking about //mergesort was selected because of it's performance, for small arrays use bubble sort (don't get me on the details, this is just an example (-: ) - document your choices and their reason. And of course keep your code as readable as possible (this is the notion that the code documenting itself).

3. RESEARCH- The internet and your colleagues being the best resources. I try to delay choosing a solution, until I'm as completely as possible sure I understand the task, the domain and the possibilities of solving it. Sounds trivial, until the first time you figure the requirements handed to you themselves should be reconsidered..

Answer 19

1) Build for what is required byt users, dont include what you think you might need in future

2) Build with deployment in mind

3) Keep everything simple