|
The cult of "minimum viable product" strikes again.
I usually fall back on the argument - "If this were a medicine would you feel confident in taking it yourself? If this were an airline would you fly with it?"
(Again - if this is a treehouse type of project then the medicine is a placebo and the airline is a lego toy)
|
|
|
|
|
Engineering looks like a pile of sheets with a lot of poorly drawn correct diagrams, awesomely drawn wrong diagrams, scraped lines, hastily written and more hastily forgotten "illuminations". Followed by smaller and smaller piles of similar sheets of improved quality.
It's the most abstract and time consuming part, requiring focused meetings (not scrum, not at all) with the minimum necessary number of people and open minds - which means that after an hour everyone goes back to solo thinking and meet the next day.
The only engineering skill that I learnt in college is to be as rigorous and factual as possible. Record all the results of the experiments, all the intermediate results and the procedures used to obtain those intermediate results and the indexes used for the decisions. Everything else is experience and personal initiative - the first requires time ("it takes a year to make a year of experience"), the latter is a tract, you have it or you don't have it.
College also taught me methods to be factual and rigorous, in the form of Mathematical Analysis, Logic, Statistics and courses of Engineering - they are useful in that they make you design standard cases with the tools used to solve them the first time and then explaining how they were solved in the first place. Basically they are history classes on engineering matters.
As for design patterns I have some trouble with the term because I have a colleague (self-taught) who misuses them on regular basis because deep down he does not understande them and makes things harder for everyone else. Then reasoning on the real meaning of the term I recognize that I use them as well, because THEY WORK, even if usaully in my team we prefer reinventing the wheel. We do embedded highly customized systems so it's usually the saner thing to do - standard components or pre-cooked desgin patterns never worked for us in the past 25 years.
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
|
|
|
|
|
Marc Clifton wrote: how do you practice it in, well, practical terms?
Someone assigns tasks during a sprint.
Marc Clifton wrote: for those with some level of college degree, did college teach you engineering skills
Schools are there to make sure you become obedient, not to convey knowledge.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Quote: Schools are there to make sure you become obedient, not to convey knowledge.
Exactly. That's why we home-school.
|
|
|
|
|
I would contend that colleges are designed to teach problem solving, in general. They are a way of transitioning from the "rigid tell me what to do" of public high schools to the "you're on your own" mentality of modern business. Some are able to put those pieces together themselves without college. Some will never understand where to start solving a problem no matter how long they might be in school. For most, however, college guides the graduates to become self-motivating and, more importantly, self-sufficient.
I would agree, and argue that it is a positive thing, that colleges do not teach what businesses want. Such information is transitory while the skills that college teaches are permanent.
|
|
|
|
|
As a member of the BCS over here in the UK I remember attending a seminar from a software engineer from the Ministry of Defence who was involved in the development of avionics and navigation software for their jets. And it was eye opening exercise. I had no idea development teams actually used things like Z (the formal programming language) in practice. The level of discipline was far beyond anything I had encountered in real life. Their procedures were extremely disciplined.
The key point is that engineering is a set of rigorous disciplines used to build applications. The level to which we employ these disciplines depends on the goals, costs and risks. It takes time, effort, cost and skill to build these sorts of systems. You therefore need to weigh these against the goals. Obviously in avionics, a software bug can lead to a fatality so higher levels of engineering discipline are required than for say a web site.
I graduated with a degree in Computer Studies nearly two decades ago where I was taught software design, Z, formal methods, computational mathematics, data structures etc. All of these can be thought of as engineering disciplines.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Great response. Thank you!
Marc
|
|
|
|
|
Dominic Burford wrote: I had no idea development teams actually used things like Z
God!
You've just brought back such horrible memories!
Working for the MoD, that was great -- we had access to any mess we wanted, for our meals (the chiefs and POs' ended up as the favourite, except on Fridays, which was officers' mess all the way).
But Z!
Logic, my @rse! It has to be the stupidest and most unintuitive way in the world to organise data structures, et al.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: It has to be the stupidest and most unintuitive way in the world to organise data structures, et al.
But.......it is mathematically provable, and that's the point. I must admit I found Z to be intuitive as it aligns with mathematics.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Hey, I don't need mathematical proof that a light switch works to enable me to switch on the light.
If you want people to find creative solutions to problems, it's better to abstract them well away from the world of Z -- but that's probably why the military likes it; "creative" is a bad word, in the military (with good reason, though. Following "The Book" is much less likely to get you and your mates killed).
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Also, I would add that a lot of what is portrayed as "software engineering" practice is, in fact, project management. Agile v Waterfall v whatever is all about how you get teams to work together on software and nothing about how you get software to work.
Many of our industry failings are human failings - but sadly we persist in trying to find technological solutions for them.
|
|
|
|
|
Duncan Edwards Jones wrote: a lot of what is portrayed as "software engineering" practice is, in fact, project management. Agile v Waterfall v whatever is all about how you get teams to work together on software and nothing about how you get software to work.
Great point!
Marc
|
|
|
|
|
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 only consider 8 or 9 subjects (from over 40) that teached me something that have been really usefull and have been using a while in work life.
At the beginning I was trying to learn a lot of stuff and got overwhelmed. Was never happy with my results and eventually got demotivated. After a time and one sommer job as electical monteaur I changed my mind and started paying way more attention to (what others already mentioned) the methodes and less to the concrete contents. I experienced an increase of my confidence and I started to feel good with it. Later on I just learned specifics enough to pass the exam. I don't remember 90% of the formulas and other concrete staff, but give me a problem of the lessons, a book related or the internet and I will be solving it after a while.
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.
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.
|
|
|
|
|
Nelek wrote: to learn how to learn. The rest came with job / life experience.
Same here.
Marc
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
