|
This article[^] describes how software engineers at Yahoo have moved away from using QA teams, and do all their own testing.
This rings alarm bells. Whilst I agree that increasing the level of quality from the development team is a smart move, I can't see how removing the QA team leads to an increase in software quality.
Unit testing was never meant to replace QA, it is a tool to give the developer the ability to exercise their code so they could automate it and run it under various scenarios and edge cases to ensure it handled them all correctly.
But that's not the whole story. As a web developer, my UI needs to be consistent with the rest of the application and I need to handle failures and omissions in a consistent manner for example. Having my code tested by a domain expert who has vastly greater knowledge of the domain area will ensure that my code enforces all the domain rules.
Having your code tested by an independent QA team isn't rocket science. It gives a level of verification above and beyond what a developer can achieve on their own.
Are Yahoo's software engineers coding without a safety net or without a clue? Only time will tell.
"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
|
|
|
|
|
IntroductionAs a design standard where I work we allow users to click on the label of a control which sets the focus to the control associated with the label. For example if there is a label with an associated textbox, then by clicking on the label, this will set the focus to the textbox in the same way as clicking directly on the textbox itself. We use this technique for all input controls such as dropdowns, checkboxes etc. This is a very simple behaviour but makes your web forms just that little bit easier to use.
Setting focus to an associated control
There are two ways you can achieve this behaviour. You can either use an HTML label control or an ASP.NET label control. Both can be used to achieve this behaviour.
Using an HTML label control
Using an HTML label you need to specify the for keyword when declaring your label control.
<label for="<%= this.textbox.ClientID %>">I am a label</label> Use the for keyword to specify the associated control i.e. the input control that is associated with the label. In the example code here I have associated the label with a textbox control. Therefore if the user clicks on the label the textbox gets the focus.
Using an ASP.NET label controlYou can achieve exactly the same behaviour using an ASP.NET label. You need to specify the AssociatedControlID keyword when declaring your label control.
<asp:Label ID="textboxLabel" runat="server" AssociatedControlID="textbox"></asp:Label> Use the AssociatedControlID keyword to specify the associated control i.e. the input control that is associated with the label. In the example code here I have associated the label with same textbox control as in the previous example. SummaryThis is a very simple tip but makes your forms that little bit more usable for an end-user.
"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
modified 16-Dec-15 1:13am.
|
|
|
|
|
Here's an interesting article[^] from Google employee Paul Lewis who works on the Chrome Developer Relations Team.
His contention is that Javascript frameworks are primarily aimed at making the life of the software developer easier, rather than providing any real benefits to the end-user.
He may be a well respected employee from the mighty Google, but I find his contention to be wrong. For starters, as anyone who has ever worked with Javascript will tell you, it is probably the most idiosyncratic scripting language out there. Saying that a framework built using this quirky and idiosyncratic language is purely to increase the developer experience is risible.
Frameworks are merely abstractions that make using the underpinning technology easier by proving a consistent programming paradigm. This obviously provides developer benefits by abstracting away the underlying details of the technology, but also by ensuring the code is more comprehensible and therefore more maintainable by enforcing a set of standards and a consistent programming paradigm.
This in turn ensures that new features can be more easily added and that bugs can be fixed more quickly precisely because a framework was used. This is obviously good for the end-user.
Javascript is the language of the web, and so its use is ubiquitous and mandatory. Therefore its use is not up for discussion. Therefore the discussion needs to be centred on both making its use easier for the developer, whilst also ensuring that the end results are acceptable to the end-user experience.
One thing that I do agree with is this final comment from Paul Lewis.
Quote: Using a framework is probably a good idea, but it’s an even better idea for developers to ensure they’re savvy about what the frameworks are trying to abstract.
I think that's something we can all agree on.
"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 read Uncle Bob Martin's Programmer's Oath[^] with interest and thought it would be useful to add a few of my own to the list. So here goes.
I promise that:
1. I will ensure that the software can be built and deployed using a repeatable and fully automated process
2. I will always employ best practice when developing software and make use of design patterns whenever appropriate
3. I will develop software in an ethical manner such that it does not compromise either my integrity or that of my employer or damage the reputation of either
4. I will willingly pass on knowledge to that of my colleagues, be they fellow developers or colleagues from other parts of the business
5. I will take constructive criticism in the spirit in which it is intended to ensure that I improve as a developer
6. I will always make a stand for quality to ensure the highest standards are met
7. I will represent my profession in the best way that I can and to be an ambassador to my profession
8. I will strive to ensure that the software I create and the process that produces it will be to the best of my abilities
9. I will strive to ensure that the software I create adds value to the business and to put the needs of the business at the heart of any technological decisions I make
10. I will use the most appropriate tools and technologies when developing software
11. I will make every effort to ensure that myself and other developers abide by this (and the original) Programmer's Oath
"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 this article[^] three architects explain the age old question of how do they balance the need to have a broad technical knowledge with having to simultaneously be an expert in certain specific technologies. For example, as a software architect you may be working on a project that consists of a Unix server running a COBOL application that needs to communicate with a set of web services that are needed by the front end e-commerce application written in PHP. To work on a project such as this you obviously need a broad general knowledge of each of the underlying technologies, as well as a deeper knowledge of those you will be working closely alongside.
I won't repeat the advice in that article (as you can read it for yourself), however, it reminded me of the point I was making in one of my earlier posts titled Seniority and T-shaped[^].
In that post I describe the concept of being a T-shaped individual i.e. one that has broad technical knowledge combined with a deeper understanding of a particular technology. Having a broad technical knowledge is obviously essential, as you can quickly get a helicopter view of the solution and see how the various components inter-relate. This needs to be coupled with a deeper understanding of the specific technology at hand, so you are able to make appropriate decisions that relate to that technology.
So to be a good software architect (although this applies equally well to developers and designers too), you need to be T-shaped. Someone who has a broad understanding of IT in general, coupled with a deeper understanding of at least one specific technology.
"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: Someone who has a broad understanding of IT in general
Dominic Burford wrote: deeper understanding of at least one specific technology.
and in my honest opinion; this only comes from years of experience.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
