|
Nelek wrote: So as conclusion I would say: The most important lesson I got from college was... to learn how to learn. The rest came with job / life experience.
Well stated; you have succinctly described the true purpose of college.
|
|
|
|
|
Thanks 
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
- Gathering customer requirements
- Software Architecture
- Support concepts (logging, builtin-help etc.)
All that and many more are software engineering, and in some terms even Usability Engineering (at least part of it) could count in as being a part of Software Engineering.
|
|
|
|
|
Marco Bertschi (SFC) wrote: Gathering customer requirements
An often forgotten step.
Marco Bertschi (SFC) wrote: Software Architecture
But what is that? How do you (specifically you) go about doing that?
Marco Bertschi (SFC) wrote: Support concepts (logging, builtin-help etc.)
Aye, logging. The architecture that I was using, courtesy of the pub/sub system I wrote, logs to wherever (PaperTrailApp being a favorite) and exceptions are caught and emailed to me (quite fun when that's in place at that get go.)
Marco Bertschi (SFC) wrote: All that and many more are software engineering, and in some terms even Usability Engineering (at least part of it) could count in as being a part of Software Engineering.
Hmm, Usability Engineering, there's something to think about.
What about "Maintainability Engineering" -- writing the code so that other programmers can easily understand it? There seems to be a tension there that I encounter a lot, particularly with junior devs, who really don't understand well enough the language (C#), the framework (.NET), and the architectural decisions that the senior developer (moi) made.
Marc
|
|
|
|
|
Marc Clifton wrote: here seems to be a tension there that I encounter a lot, particularly with junior devs, who really don't understand well enough the language (C#), the framework (.NET), and the architectural decisions that the senior developer (moi) made.
They will eventually get the point and learn from it.
Last job we were 3 seniors at the end, one was often abroad, the other has no patience, so I got the privilege of teaching the newbies. My first 3 days were just about... naming, commenting, documentation and my list of best practices. Then we got into theoretical aspects of the programing enviroment and the PLC intern structure. Then started with real program examples (my biggest project and the software I was most proud of), I really doubt any of the ones I teached had been confronted to something more exhaustive than that.
They all flipped out the first month, but at the end (when I quitted the firm) all came to me and told me different variations of "thanks for kicking my ass at the beginning, it later made my life easier"
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Marc Clifton wrote: Marco Bertschi (SFC) wrote: Software Architecture
But what is that? How do you (specifically you) go about doing that?
Data Streams, Business rules and customer restrictions (e.g. "Can't be connected to t'internet") and so on.
At the moment we use an approach where we have our Entity Data Model encapsulated by a Business Domain Model, where a Shared Business Layer handles access to the entity framework and only displays Business Model objects to the top.
|
|
|
|
|
Marc Clifton wrote: Hmm, Usability Engineering, there's something to think about.
I did the Foundation Level (CPUX-F) - International Usability and UX Qualification Board[^] a few months ago. IMO at least a basic udnerstanding of usability should be part of every developers epxerience (except maybe embedded programmers  ).
If you want my 5 cents on Usability Engineering in the article drop me a PM.
|
|
|
|
|
Marc Clifton wrote: how do you practice it in, well, practical terms?
Well basically as you list it up, i go from idea to the lowest block of work / module / codepart.
So i start with a big overall architecture, split it up into themed blocks and then reduce those further. I try to fit in patterns and stuff, according to what my product should achieve. Think about security and logging. Make plans and detail all the functions, generate tests and so on.
For example i have a big overall (ListOfCustomersProgram), this gets splited into business code (doing the work) dataCode (DBO/Models) and the UI (Usercontrols) and then i split those parts even futher. After connecting the parts i decide where to split into Frameworks / .dll and which parts i can modularize into separate projects.
This is just a small part of the whole engineering though 
And that's engineering for me, at least kind of.
Marc Clifton wrote: I'm also curious, for those with some level of college degree, did college teach you engineering skills, or did you learn them yourself or on the job?
We got the modules SoftwareEngineering 1 and 2 so actually i had 2 semesters on dealing with this things. But i can't remember everything we learned there
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
Since developers have no Engineering certifications, it really comes down to how each of us individually define "Software Engineering".
For me, even though my job title says "Engineer" and I have 20+ years of experience, I don't consider myself a Software Engineer. Here's the hierarchy I have in my mind:
Engineer = Missile Guidance, HFT, Embedded Medical Devices, etc...
Developer = LOB applications (order entry, accounting, etc...) <- This is where I am
Coder (or Script Kiddie if you prefer) = "Apps"
However, having said that, for every missile guidance system out there, there's thousands of "apps". So it makes perfect market-based sense that for every missile guidance Engineer there would be thousands of app Coders.
|
|
|
|
|
Vark111 wrote: Engineer = Missile Guidance
Hi, I'm Denis and I'm an Engineer. I'd LOVE working for Missile Guidance Systems... but I'm stuck with X-Rays. 
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
For greenfield or brownfield projects, a PM or me will create a high-level project plan. After that fun stuff, I’ll create the following: Architecture Diagram, ERD, ETL Migration (if needed), web page topology, if I have that info, and then we’ll start have meetings. If requirements are easy, me or another developer will run with it. If moderate to very difficult, I’ll do a fully dressed use case. I don’t like user stories as they don’t tell me much, though I have worked in a S**** projects. For the UI, I have sat with the customer and drawn out prototypes on the board or paper or even used post-it notes or viseo diagram by email; so they can visualize and get an idea of how the functionality will work.
15 years ago, undergraduate studies taught me very little about SE. There seems to be one class where we developed test cases; besides that, nothing. In graduate school 10 years ago, I took several software engineering courses that covered UP/RUP, UML, and software development methodologies; we even touched on Agile, Scrum, Crystal, and Lean. I have utilized some RUP tools such as Sequence diagrams and System Sequence diagrams. I see a lot of RUP in today’s tech, just reworded or reworked.
I have noticed over the years that many of the best coders or IT people have neglected the software engineering aspect and many times they have a BS to no education.
|
|
|
|
|
Marc Clifton wrote: I'm also curious, for those with some level of college degree, did college teach you engineering skills, or did you learn them yourself or on the job?
Back when I went to college, they thought that teaching people to program was sufficient. Not even the higher degree classes covered what we do today as software engineering. So, everything I learned about that end of things has been taught to myself, sometimes on the job, but also sometimes not.
Incidentally, it isn't just software engineering that's dead, it's all of engineering. Case in point, the Boeing 787 battery[^], wherein the solution wasn't to redesign the battery not to catch fire, but merely vent to the smoke from the fires better. I think the younger generation is so used to building on the shoulders of giants, that they don't realize how much work went into making those shoulders, and therefore think anything that's hard to do doesn't need doing.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
I haven't read all of the replies so far (tl;dr) but I'll cherry pick a couple of points...
Marc Clifton wrote: when you think of software engineering, how do you practice it in, well, practical terms?
In my experience, an enterprise will hopefully pick the management style somewhere on the specturm from waterfall to agile. There are places where each is correct and the typical answer is somewhere between the 2 extremes. Medical devices and aerospace with well defined requirements should use waterfall. A consumer app with a fickle customer showing lots of feature creep should be agile.
Marc Clifton wrote: for those with some level of college degree, did college teach you engineering skills, or did you learn them yourself or on the job?
I started programming in the 1960s. Back then, you learned programming skills using the technology of the day. Computer science is a relatively young technology - arguably about 60 years old - and still evolving today. I have an Engineering degree (EE) and Computer Science degree. My EE training taught me how to think like an engineer. I would guess that about half of the technical skills I have learned have occurred since I graduated. College gives you technical skills but not project management. All management skills (project management and otherwise) I acquired came from life in the real world.
One of the metrics that I have found useful over the years is the count of lines of code per man day on a project. When I was in college, I felt I could typically generate about 300 lines of code per day ("man day") for assignments. In the real world, work on a project in a generic app would give about 8-12 lines of code per man day (including developers, testers, project manager). In critical apps such as medical and flight, the number is less than 1 LOC/man day... regardless of the language used. ...The point for this discussion being that different management styles produce different productivity levels, and reciprocally different product quality.
[Tangentially, this to me has been part of the justification for use of as high level a language as possible, since both productivity (LOC/man day) and bugs (bugs/KLOC) are relatively constant regardless of the language used.]
I'm retired. There's a nap for that...
- Harvey
|
|
|
|
|
Engineering is a mindset that's not available to a fair proportion of people who get paid to program*, so it's really more about where your head is than processes.
Engineering is 50% investigation, 35% preparation, and 15% implementation. Those proportions are not always needed for software, true, but they go completely out of the window, when the first thing someone does is sit down and start writing code.
* Can we say "euphemism", children?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Software engineering is dead - Actually Software engineering doesn't exist for scripting language like JavaScript, Python , Ruby. Has never worked from entire experience. Time estimation, analysis , design everything is just pain for delivery.
Software Engineering does really work well for primarily created as Typed, OOD based languages like Java, C++, C# , ... Off course there will be a heavy duty along doing it so.
One question though, how they are doing things like pub/sub in script language. It just a puzzle to me as of now.
|
|
|
|
|
prototypes (that don't turn into production code)
hahahahahahahahahhahaahahahahaa
< silence >
|
|
|
|
|
This topic is depressing.
I recently fell into consulting because I couldn't get a job. I tell prospective employers: I'm not a rockstar, I'm not a coding ninja, I'm old/pedantic/thorough and therefore slow. I'm not a senior developer, I've only been doing development for about 8 years now (4 years embedded C, 4 years iOS). I don't like Agile (enabler of rockstar haxors and script-kiddies) so I'm not gasp a team-player.
I have no formal training except for about 3 months fulltime, pre-2000. The thing is, during those 3 months our instructor gave us little extra exercises, and I went home and did them. I showed him my code, very puffed up as you can imagine. He rewrote my 20+ line function in about 5 lines, with 2 nested loops. Mind blown. 
I learnt that there is always a better, more elegant way to do something, and I've been trying to achieve it ever since. So I read about best practices, design principles, architecting, becoming a better programmer (which is why I'm on this site  ).
In embedded development I learnt there are no shortcuts. You really need to architect your stuff properly, because it's going to grow like a fungus in a dung heap. And the POC you're told to do today is sold as a feature tomorrow, so just do it properly and save yourself a lot of pain.
It seems to be an older mindset, wanting to improve and do better with every project, and build something lasting (or as lasting as software can be). Whereas the younger developers seem to want to learn every new, sexy language, but just enough for "Hallo World", and play with fun new technologies. Build it today, throw it out for the next thing tomorrow.
This instant-developer-just-add-beer world isn't for me 
|
|
|
|
|
Marc Clifton wrote: prototypes (that don't turn into production code)
Ba-ha-ha-ha-ha! As if!
Just kidding, Marc. To be fair, I have a very rational (from a tech standpoint) partner on the business side. He understands and is good with us iterating on bigger things. We'll often discuss some project, and figure out good milestones where we can release, and give some improvements, all the while moving toward our ultimate goal.
I find this approach also helps when he gets the (almost) inevitable push to change priorities. Then we have project #1 in a spot we set aside (or close to, and get to the next milestone), and move to project #2.
Marc Clifton wrote: I'm also curious, for those with some level of college degree, did college teach you engineering skills, or did you learn them yourself or on the job?
I think I went to college far too long ago for this to apply too much. Even then, most of what I think most people consider my strong points are specifics learned on the job, but generally just part of my personality (detail oriented, enjoying figuring out a solution to the problem).
|
|
|
|
|
I have written many articles on the lack of actual software engineering practices in software shops.
They may help you with some of your thoughts on your upcoming article.
You can see all of my articles at the following link... https://blackfalconsoftware.wordpress.com
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
I attended college but it was mostly Computer Science. The engineering part came by experience.  
Go, write your book, it's always welcome. Please tell us when it's in print to buy it 
|
|
|
|
|
The Software Engineering Institute at Carnegie Mellon Institute had a long history of attempting to justify the application of "engineering" to software development through the Capability Maturity Model. The model recognized that software, as a developing discipline, lacked the "best practices" and "working methods" that allowed older engineering disciplines to create qualification exams. So the CMM codified management practices that would allow organizations to discover and document those practices and methods.
This was all swept away in the internet craze and economies of scale driven by zero cost of distribution. Software engineering practices are the competitive advantage that keeps Microsoft and Google and Amazon in the money, and they are not likely to surrender them. This is evidenced by the surrender of IP to open source. It doesn't make a difference whether you can get the code if you don't have the discipline to do a thorough V&V of the product as a whole - nobody spending cash money is going to trust what you wrote.
Where this has led, in the C# world, is to a steady drip of language features that allow coders to do their work faster. This manifests in (C#) attributes in the persistence framework and keywords that simplify threading and make properties behave like public (class) attributes . The upshot is that hackers can hack faster (including thinking of asynchronous processing as sequential logic) because Microsoft does the engineering behind the scenes to ensure that signals are produced and work-arounds available when something unexpected happens.
The paradox that should be recognized is that the engineering is organized to allow most developers to avoid engineering. Except in control systems, time-to-market is king, and the APIs provided by the major players ensure that application failure results in lost business, and not consumer fraud.
Eventually this will work its way out, because ultimately its engineering practices that allow IP to carry over from generation to generation. It's only those companies that do engineering that will survive the retirement of their lead developers.
|
|
|
|
|
Marc,
You pose an interesting question, and the answer is...
Id Depends...
Okay, for smaller pieces we gather the core requirements and iteratively get things finished.
For more complicated ones, we actually split it up into pieces, and then apply engineering concepts ONLY where needed (are we use MQ, enquue, or our ownque). Leveraging previously well working designs (kinda like using patterns), but we do NOT share the code, we copy it (unless we already made a library).
Sometimes we shoehorn a solution into something we already have working (leveraged an existing DB that the clients had access to, but now for a different project, which turned out to be useful later in the project when they actually needed to show some of that data!).
The goal is KISS. Can I explain it in 30 seconds. Can anyone identify the single points of failure? How resilient does it have to be? (If it goes down, will it halt production on the floor).
Then, each box is treated appropriately. Many solutions are NEVER a single EXE. We often have daemons, services, GUI/Clients, and intranet/html.
We apply different levels of engineering to different layers. We mandate logging, and indications if we are running in Production, Staging, Test or Developer environments.
We apply code reviews, and sharing of best practices (removal of worse practices).
Did I learn any of this in College? Yes. In fact, my late professor challenged me to write a simple program: Add 2 numbers. And then guarantee it's correctness. Warning me that I was not allowed to make any implied assumptions. All assumptions had to be stated. (Both numbers had to be integers in the range of 32 bit integers, and adding them together cannot exceed a 32 bit integer, etc. etc. etc).
And I failed.
I Falsely assumed the hardware would add correctly, without listing it as an assumption.
I argued that was unfair. A few months later the Pentium F-Div bug showed up. And he rubbed my
nose in it. (BTW, they built a computer, he was on the team, and they had a cold soldering joint on one of the data wires, and it was causing the math to behave funny, which is why he uses it as an example).
In the process, I was taught to think WAY BEYOND my software. I find it incredibly helpful. And I have had the experience that Power has been questionable, Hardware has issues, the definition of daylights savings time changes, and upgrades cause old working code to suddenly break.
We work on a layer of assumptions that is simply astonishing.
We build software on an even bigger layer of assumptions.
Kirk Out!
|
|
|
|
|
It's not dead. Just resting...
The root book of the software engineering movement is (IMHO) Fred Brooks' The Mythical Man Month. He wrote that book about experiences he had in 1967, and spawned a whole sub-discipline of computer science. Only, we still haven't learned the lesson fully.
Do developers always use all available tools from software engineering? No, don't be silly.
Do mechanical engineers do a stress analysis on every box they design? No. Why should they? Well, should they? Yeah, sometimes.
People rush right to coding for a variety of reasons; they think the problem is easy. Their manager is pressuring them to produce. They're human beings, who are lazy when they can be. It doesn't matter to customers if the code works right every time.
But the fact that some devs are lazy and some managers are ignorant hardly means software engineering is dead. Somebody is writing software for space probes, commercial aircraft, and nuclear reactors. And these things fail less frequently than they used to. Some web sites have performance so rock-solid that you don't even think about them going down. These are places where software engineering is being practiced. People whine about how these companies are so bound up in process that it's impossible to get anything done...anything, that is, but rock-solid quality code.
|
|
|
|
|
You can't call it engineering until some objective measures can be applied to the whole endeavour of software development; of which there are very few.
Mathematics and science does factor in some ways (e.g. code metrics or relative performance of algorithms) but taken out of context of requirements, design and success - in the business sense - not that much help.
To put it another way, there is no way to observe an existing project and predict it's outcome, even with a margin of error. You can't observe a software developer and objectively measure their performance either. Nor can you apply any true measure to a team.
To describe software engineering as dead, misses the point. It never was alive as an engineering discipline because the basics have never been discovered let alone applied.
At the moment it is an artistic endeavour. The best analogy I've come across is the comparison to a team sport where science helps, but cannot fill in for the human factors.
Frustratingly I'm not an academic so I'm not familiar with any formal studies, but I do know some are being made. However, the studies I have read about don't, IMHO, control the myriad of variables correctly or mitigate them through wide statistical sampling. Not convinced they are asking the right questions either.
If I ever had the opportunity I would perform a range of studies to try and uncover some fundamental truths about software development. For prosperity here is a list of studies I would like to see done;
1. TDD vs non-TDD
2. How effective is refactoring?
3. Does documentation help a new developer?
4. Is pair programming more effective than lone development?
5. Is it better to learn through documentation or pair programming?
6. How accurate are comments?
7. Is bug fixing more expensive than good design?
8. Is untidy code more fault prone?
9. Are some requirements more error prone than others?
|
|
|
|
|
If you separate 'PokeMon GO' differently you could read: poke mongo
Please don't poke the mongo.
Kitty at my foot and I waAAAant to touch it...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
