|
Slacker007 wrote: and in my honest opinion; this only comes from years of experience.
And I would agree completely 
"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
|
|
|
|
|
After reading this article[^] on the management style of Linus Torvalds, the creator of the Linux operating system, you'd be forgiven for checking the date to check you hadn't been transported back to a time when workers had few rights and their employers could treat them as badly as they wanted with impunity.
The fact that this sort of anachronistic, bullying behaviour still exists is a tragedy. The fact that someone as high profile as Linus Torvalds is guilty of such behaviour is an even bigger tragedy. And not only that, but his bullying, intimidating style of management has set the tone for everyone else who works within the Linux kernel community. The Linux kernel community is a toxic place to work, where tearing people down in public is the norm.
The modern workforce has no place for such people or their styles of management. What Linus Torvalds doesn't realise is that this is not the way to get the best out people. No one rises to greatness because they were publicly humiliated. No one becomes inspired because they were verbally bullied.
Linus Torvalds openly admits that he doesn't care for people, he only cares about the technology. That's fine, in which case he should immediately stop having any dealings with those people for whom he doesn't care. He should delegate someone else with better people management skills (which shouldn't be difficult) to do the job, and let him focus on the technology.
What he fails to grasp is that he has probably prevented many top programmers from coming anywhere near his product as they (rightly) don't want to work for a bully in a toxic environment.
Linus Torvalds may be a driven, motivated technological genius, but where he fails so spectacularly is as a decent human being. It costs absolutely nothing to be considerate and respectful to those around you. These are the basic traits you expect from someone else, and so should likewise be the way you treat other people.
It also doesn't endear you to anyone. No one is going to go the extra mile for someone who doesn't have their best interests at heart. In business terms, you will quickly be isolated as no one wants to do business with you (evidenced by his rant at NVIDIA the graphics giant for not providing decent support for the Linux operating system). You will also lose top talent, as evidenced when Sarah Sharples left the Linux kernel community as she could no longer work in such a toxic environment.
So his management style has isolated him within the wider technological community, and lost him top talent too. If that doesn't speak volumes then I don't know what does.
So even if it was only for purely self interested reasons, being a decent human being wins the hearts and minds of those you want to do business with, and they will far more likely be willing to help you realise your vision.
If you treat people poorly, then don't complain when they don't want to help you any more.
"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
|
|
|
|
|
Dominic Burford wrote: If you treat people poorly, then don't complain when they don't want to help you any more.
|
|
|
|
|
Having read the the following article[^] I can't quite make up my mind if the article is simply clickbait or if the author genuinely believes the position they have described. I will give them the benefit of the doubt and assume that they are being genuine.
The article certainly is lengthy and the author could easily have made the same point using half the words, but let's forgo that for the time being.
The main gist of the article is that programmer are not engineers and should stop calling themselves engineers (as in software engineers). I think we can all agree that there have been a lot of high profile failings that have been attributed to software failings, especially in the area of data security breaches (I will take huge exception to the example of Volkswagen though. This was an example of corporate fraud mandated by those at the very top of the Volkswagen pyramid, and not the lowly engineers at the bottom).
Those examples aside, to dismiss those people who create software for industries such as aircraft navigation or nuclear power plant safety where mistakes in the software can be fatal is insulting. Or those working in the banking and finance sector who ensure our mortgages get paid on time and that we can get to our money on any high street. I could go on, but the point is that there are a great number of people working in the software industry who develop robust and fault tolerant software. Who use industry best practice and write software of the highest quality as the consequences of doing anything less would be catastrophic.
I'm not sure what underlies the author's stance, but they are wrong. They are perfectly entitled to their opinion, but it is one that I personally do not share.
"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
|
|
|
|
|
In his book The Art of Unix Programming[^] Eric Raymond proposed the Rule of Modularity.
Quote: Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging complex code that is complex, long, and unreadable.
The Rule of Modularity is at the heart of Object-Oriented Design. Decomposing complex problems into a succession of smaller and more comprehensible problems which a human brain can reason about. Abstraction and encapsulation are fundamentally ways of managing complexity, and both have their roots in the Rule of Modularity.
The human brain is not yet evolved to tackle complex problems head on. A brain that was originally wired to hunt and build simple tools continues to struggle to fathom the complexity at the heart of software development.
The Rule of Modularity and the book from which it is derived is as relevant today as it was when first published over a decade ago in 2003. The book describes many of the ideas and wisdom from the early, pioneering days of computing dating back to the late 1960s and distills them into a book that is applicable to modern software development.
Software development is concerned with solving problems, and these can often be big, complex problems. Ultimately this means managing complexity. It shouldn't be in the least bit surprising that any mechanism that allows a human brain to manage this complexity should continue to be so successful.
"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
|
|
|
|
|
I have written an article previously on the topic of Domain-Driven-Design[^] (DDD) and so was intrigued when I came across this free condensed version of Eric Evans's book called Domain-Driven-Design Quickly[^]. Having just finished reading it I can recommend it to anyone wanting to learn about DDD but may find reading the original book by Eric Evans a little daunting (it's around 500 pages so not a quick read).
For those people who have already read the original book, it provides a very useful summary of the book. It doesn't assume that you have read the original book or have any familiarity with DDD at all.
I found this book to be a very useful summary of the original book by Eric Evans. If you are serious about learning DDD then I would highly recommend you purchase a copy of the original DDD book by Eric Evans. If you have already read the original or just want a concise summary of the main ideas of DDD then this is the perfect book.
"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
|
|
|
|
|
Nice. I subscribe to your blog, thus I am notified when you post something new. Keep it coming.
I know nothing about DDD, but have heard about it. I think I shall look at this further. Might help my team and I out with some issues for future work designs.
|
|
|
|
|
Quote: Nice. I subscribe to your blog, thus I am notified when you post something new. Keep it coming.
Ah you're the one
Glad you enjoy my posts.
I've been looking at DDD for a while now, and can definitely see its value. It's not a design pattern or design methodology, it's a way of modelling your software so that its a true reflection of what the domain behaviour. You develop software in conjunction with domain experts. You share a common language to ease common understanding. Your software should be easily understood by anyone with similar level of domain knowledge.
The good thing about DDD is that it doesn't require any new tools or technologies, just a different approach to designing your software.
I'd definitely recommend looking into DDD and see what benefits it can bring to your next project
"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
|
|
|
|
|
There is a well known story that about a woodcutter who stops periodically to sharpen his axe will. This woodcutter cuts down more wood than the other woodcutter who doesn't. By periodically sharpening his axe, the woodcutter is more productive than those that keep on cutting without stopping, as eventually their axes become blunted over time and they become less efficient.
A similar analogy can be made with software development. The analogy being that the developer who periodically stops writing code to research new ideas will be more productive than the developer who doesn't.
There are many ways of keeping your skills up-to-date. Here are just a few.
- Reading articles
- Writing articles (if you understand it well enough to describe it, then you understand it)
- Contributing to communities, forums, open-source projects etc
- Using social media to keep abreast of what's happening e.g. Twitter is great for this
It's important that it doesn't become a chore. Keep it fun and you'll keep doing it. I try to spend a little time each evening reading around various articles that I find on Twitter. I also enjoy wrtiting technical articles. Not only do I enjoy the warm fuzzy feeling of passing on my knowledge to
others, but it also forces me to research a subject and thus increase my knowledge.
Keep it fun and make it a regular part of your daily routine.
Remember.....keep your axe sharp
"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
|
|
|
|
|
Agreed.
Doctors and nurses have to keep their skill set up-to-date as well.
|
|
|
|
|
Absolutely, many other professions need to keep their skills up to date. Sometimes this is a professional requirement as it is with medicine.
"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
|
|
|
|
|
Following on from Truths about software development Part I[^] and Truths about software development Part II[^]
1. If I had a pound (dollar) for every time I heard the phrases "How long will it take" or "How much will it cost" I'd be a very rich man. Good job I'm not waiting to hear the phrase "How about the quality"
2. You will always think of a better solution to the problem you resolved 5 minutes after it gets released to the customer
3. You look at code you wrote just last week and wonder what the hell you were thinking
4. There is always that one developer who writes awful code no matter how much time they have to write it
5. No matter how much effort you put into staying current you'll always be asked about that one technology you haven't got round to looking at yet
"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
|
|
|
|
|
|
I think there is a subtle difference between staying current and improving your knowledge. Admittedly both allow you to gain new skills and / or knowledge, but whereas one builds on your already existing knowledge, the other brings you new knowledge.
For example, I have read Eric Evans's excellent book on Domain-Driven-Design recently, and it made me look at software development and architecture in a whole new light. That was improving my current knowledge because it built on top of my already existing design and architectural knowledge. I have also recently been learning Node.js, which is staying current, as I am new to Node.js and don't have any previous knowledge to build upon.
It's important to keep building upon your existing knowledge, as well generating new knowledge. Good software developers need to do both.
"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
|
|
|
|
|
Reading this article[^] got me thinking about what does it mean to be a senior developer? For me, seniority equates to knowledge, and is not related to the number of years experience you have. If you have worked for the same company working on the same product for 10 years and not made any particular impact on the team, does that make you more senior to someone who has worked for 5 years but has been exposed to a greater number of technologies, methodologies and constantly brings new ideas to the table?
In my opinion, it does not. Seniority is about the depth and breadth of your skill set. You may have 10 years of commercial software development under your belt, but if you don't understand architecture, design patterns and SOLID principles for example, then how can you possibly call yourself a senior developer.
This is where the T-shaped individual[^] comes in. For those that haven't heard of the expression, it relates to an individual who has both deep experience in a certain area, but also has a wide breadth of knowledge across the entire discipline. So for example, if you have a deep knowledge of web development with ASP.NET then you have deep experience of a particular technology. To be T-shaped you would need to complement that with knowledge of a wider (broader) set of skills such as (for example) architecture, design patterns and SOLID principles. The wider (broader) your skills, the more easily you can pick up new ideas.
Being a whizz web developer is all well and good, but if you can't pick up new ideas and skills as you lack the surrounding context and interrelated disciplines, then that makes you a one-trick pony. Good for one specific thing, but not a lot else.
The wider and deeper your skills the more T-shaped you are, therefore the more value you add to the business.
"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
|
|
|
|
|
In light of the recent Volkswagen emissions scandal[^], it has been reported that the smart software that is loaded into the Volkswagen cars was responsible for the cars deliberately reducing their emissions when under test conditions. This calls into question the ethics of the software engineers who were responsible for making such changes to the software. They deliberately and knowingly subjugated the software so that it would return misleading results when under test conditions, and thus give false and invalid readings.
I have written about ethics in our profession previously[^] To be considered a profession we need to act like professionals.
It almost goes without saying that you expect this kind of underhand behaviour from boardroom CEOs and their kin, but this is unexpected behaviour from our industry. They were complicit in the scandal that is now facing their employer. They quite simply have no excuse for what they did.
They must surely have known what they were doing was wrong, but went ahead anyway. Saying they were under orders to make the necessary changes is no excuse either (the Auschwitz defense). Maybe if they had taken a stand and refused to make the changes to the software that was asked of them, this whole sorry mess could have been avoided.
"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
|
|
|
|
|
They clearly hadn't read this: https://www.acm.org/about/se-code[^].
But I wonder what most of us would do if put in that position? If asked to do something ethically dubious, would we put our jobs on the line and refuse to participate? That could be the subject of an interesting (and anonymous) survey.
|
|
|
|
|
I don't think the issue of ethics in our profession is discussed enough, and the current events at Volkswagen are a sorry testament to that.
Whilst some may fear losing their jobs, which I fully understand, I wonder how many will lose their jobs anyway as Volkswagen seek to pay the substantial costs that this has incurred (into the billions by all accounts). I also wonder why there wasn't a whistleblower. Even if I opted to stay for fear of losing my job, I would certainly not want to remain complicit. I would seek to become a whistleblower and inform the necessary authorities.
By all accounts, this is a sad testament to our profession.
"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
|
|
|
|
|
How easy to say in your shoes. What is the alternative ? Cancel a $300,000,000 engine development due to bad emission tests that you can workaround with twenty lines of code ? If you intend to do that, please film yourself announcing your steering committee that you will not make the change, and send me the video. And also film yourself while trying to find another job, because nobody will hire you anymore after such a move.
Plus this is daily stuff in the car industry : entire development departments must "bend" test results so that the final product match specifications. Do not blame the people, blame the system. All car manufacturers, tier-1 or tier-2 or tier-3 are cheating on some of their figures and results. Changing software is cheap, changing hardware is expensive, this is reality.
Do not get me wrong : I do not think this is good, and that one case in a billion now lead to a "scandal" is good, but this is peanuts compared to other things going on in the car industry, in the pharma industry, in the finance, etc...
Also do not assume people that made the software were fully aware of what would be done with the code : I can ask tomorrow an external company to write a software for a prototype that would block the steering wheel when a sensed temperature goes below zero, the day after tomorrow another company to write a software for a prototype that sets the temperature value of the sensor to -50°C if you hit the brake, and combine the two in a series software that would bring you right in the wall everytime you hit your brakes.
|
|
|
|
|
This had nothing to do with innovation or development, but everything to do with deliberately subjugating the rules governing the levels of emissions that are legally allowed. This was not some minor point of detail, but a deliberate attempt to sabotage the test results across an entire continent.
Ignorance is not an excuse for what happened.
We will agree to disagree.
"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
|
|
|
|
|
Dominic Burford wrote: This was not some minor point of detail
Exactly my point : Compared to everything that is being made, this one is for sure one point of detail.
Now, since you are not part of the industry, and therefore are not aware of what is usually being done there, it appears to you as something unbelievable.
Do not judge too quickly, and do not underestimate the importance of the context.
|
|
|
|
|
VW as a company put profit before the safety of the general public. Air pollution is a growing problem globally, and cars are a major contributing factor in that pollutions. The development team who rigged the software on the cars to give misleading results under test conditions did so knowingly and were therefore complicit.
Ethics and integrity were absent during this entire sorry episode. From the top all the way to the bottom.
I personally can find no mitigating circumstances to any of this whatsoever.
As I said before, we will agree to disagree.
"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
|
|
|
|
|
Dominic Burford wrote: The development team
You are talking about several hundreds of people here, spread worldwide, in different companies, not just two developers sitting at a desk.
Dominic Burford wrote: I personally can find no mitigating circumstances to any of this whatsoever
Yes, because you choose to ignore context and reality, and because you judge people from what you have heard in the news. I would agree with you if we were living in an idealistic world, but life is not black and white, and this case is far more complicated than just "OK, they decided to cheat at a large scale, this is unethical".
I find it awesome that you are defending ethics and integrity in a world that has never lacked them more, with tendency growing. IMHO, you should be less categorical in your positions to gain credibility : evangelism serves no purposes.
|
|
|
|
|
Like I said, we have different positions on this. You are making the assumption that yours is the only one, and that makes you fail to see or appreciate other positions on the matter.
I take a stand for ethics and inegrity in both my professional and personal life. I champion and campaign for social justice and equality in many aspects of my life. The fact that the rest of the world may be lacking in such things is precisely why I take the stand I do.
I do not think it me who is being naive or categorical on the issue.
As I have said (twice) before. We will agree to disagree.
"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
|
|
|
|
|
Dominic Burford wrote: I champion and campaign for social justice and equality in many aspects of my life
Dominic Burford wrote: We will agree to disagree
To me, this does not fit go together. Either you campaign, and then bring arguments to defend a cause and get people to side your opinions, or you simply have a view on something and disagree with everybody else, which is not really campaigning.
Do not get me wrong : I am not trying to start "yet another fight" on the internet[^], it is just that I have been trying to explain why this happened and why nobody was shocked about it in a given context; this does not mean that what has been done was good (which I have already said twice), only that your target, namely the SW development, is IMO the wrong target. In one of the earlier post, you seemed to be surprised a company put profit above all, this is to me a very naive approach of the world -> give me only one example of a big company that is putting something upon making profit ? Again, I do not think this is good, put blending it out because we do not want it to be there is a curious way to go.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
